Re: [gtk-list] curious time overhead for vscales

[Paul Barton-Davis <pbd op net>]

In message <20000218020115.20131.qmail@hyperreal.org>you write:
>Check this out if you might have insights (or concerns) about the
>overhead of multiple updates to multiple vscales. :)
>
>Eric

Before I start, let me just note that I am not sure of the design of a
program that does updates to any visual widgets at much more than
140Hz, since thats twice the typical refresh rate of a monitor. What I
normally do in these situations is to modify some internal state
thousands or even millions of time a second, and each time just queue
up an idle function *if one is not currently queued*. the idle
function unsets the flag that indicates that its been queued, and then
proceeds to do whatever is necessary to map the state of the variable
into the visual display. that way, updates happen with close to the
maximum update frequency.

Anyway, continuing with the matter at hand:

I am not sure I understand this either, but here's my guess:

First, recall that the X protocol is asynchronous, so you can send
several requests before getting a reply to the first one. 

Then, recall that GTK batches updates, and mostly talks to the X
server only at the end of an iteration of event processing. In the
first case, you modify 10 vscales 100 times a second; thus, 100 times
a second, a bunch of stuff gets sent to the X server to update the
current screen display.

In the second case, you communicate with the X server 1000
times a second.

The amount of information sent in each case does not differ in size by
a factor that balances out the frequency difference. Hence, the first
case uses less CPU because you're actually doing less communication
with the X server.

You could test some of this by using the server or the program with an
option to force synchronous communication with X.

--p