Le primidi 21 vendémiaire, an CCXIV, Paul Davis a écrit : > in this example, the problem is really related to rounding. > g_timer_elapsed() will return the correct value, but you round it (in an > unpredictable way from a portability perspective by casting to int) to > some integer number of seconds. if you always rounded to the nearest > integer, you would not see the irregularities you describe; rather the > clock's imprecision would be limited to 0.5 seconds, which is the > smallest it can be possibly be. > > the clock does not get progressively less accurate over time. its > accuracy is always the same: +/- 0.5 seconds, and that is not because of > the way the timeout is called, but because you wanted a second- > resolution clock. You get me wrong here. What I want is not a clock that at all time displays precisely the current internal time; of course, with 1 second precision display, there is up to 1/2 second différence. What I want is a displayed clock that *changes* precisely at the time the internal clock value changes. With careful programming, I can get that with "precisely" = the intrinsic system latency, which is pretty good (less than a CRT screen refresh, on idle modern systems).
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
