Le primidi 21 vendémiaire, an CCXIV, Paul Davis a écrit :
> trying to get accurate timers within a GUI event loop is like trying to
> stay upright while walking across oil on a frozen lake.
>
> there is no nothing to prevent a GUI event handler from taking so long
> that you miss entire "cycles" of your timer.
>
> if you need accurate timing, i suggest you see it outside the event
> loop.
I believe we are not talking about the same accuracy here. Let me again use
my example of a timeout that updates a clock on the screen, because that is
what I have in mind right now.
We can have several levels of accuracy of the clock:
- Perfect accuracy: the clock is at all time precisely up-to-date, even if
the system is overloaded with expose events and other processes.
- Bad accuracy: there is a human-perceptible lag between the clock and the
internal value it should display, even when the system is idle.
- Good accuracy: when the system is idle, the clock is up-to-date with no
perceptible lag, but if the system becomes too loaded, then there will be
a lag.
Perfect accuracy is not possible without major system redesign, I am aware
of that. But "good" accuracy is easy. Alas, the current g_timeout_*
functions only give us "bad" accuracy.
To answer Greg Breland's question: here is the typical piece of code one
would use to display a second-accurate clock:
GtkLabel *clock_label;
GTimer *clock_timer;
...
clock_label = gtk_label_new("0");
/* add it somewhere in the GUI */
clock_timer = g_timer_new();
g_timeout_add(1000, update_clock, NULL);
g_timer_start(clock_timer);
...
static gboolean
update_clock(gpointer dummy)
{
char buf[10];
sprintf(buf, "%d", (int)g_timer_elapsed(clock_timer, NULL));
gtk_label_set_text(GTK_LABEL(clock_label), buf);
return(TRUE);
}
But look at the actual times where gtk_label_set_text will be called on a
moderately-loaded system: 1.005, 2.01, 3.015... 60.300... 120.600. After
just two minutes, the clock display is more than half a second late, and at
some time, it will just jump from, let us say, 199 to 201.
Of course, it is not dramatic, it is just a label that is a bit late and the
internal state of the program is coherent, but it is not satisfactory: what
is the point to have a second-accurate display if it is more than half a
second late half of the time?
And think of a chess-game clock: for quick games, having 2s left or having
1.1s left may make the whole difference (well, it may be a good idea to
switch to 1/10s display at the end of the game, but here is the idea).
So timeouts that try to catch up are not an absolute necessity, but they are
quite useful in some programs.
Attachment:
signature.asc
Description: Digital signature