Re: paint clock

[Havoc Pennington <hp pobox com>]

Hi,

On Sat, Oct 2, 2010 at 7:32 PM, Soeren Sandmann <sandmann daimi au dk> wrote:
> FWIW, I put up the notes I wrote about this subject here:
>
>        http://www.daimi.au.dk/~sandmann/framehandlers.txt
>
> They were written with a different toolkit than GTK+ in mind, so they
> make various assumptions that don't apply to GTK+. For example the
> widgets are assumed to not do anything like gdk_window_process_exposes().
>

Very interesting!

We've messed with various things smarter than what I described for litl shell.

Right now it's "do stuff for up to 5ms only if there's anything to do;
then paint immediately." This gets throttled by the vsync. We never
install a timeout or sleep as long as we have a paint queued.

We had terrible luck with anything that involved installing a timeout
(i.e. polling with nonzero timeout). In part this may be that the
shipping litl product is based on 2008 or so Linux which I believe has
10ms resolution on poll timeouts... so the noise in timeouts is
already half a frame. This just can't end well. I believe newer
kernels have high-resolution timeouts though... all I know on this
subject is from
http://lwn.net/Articles/296578/

I think another issue here was that frames are just not that uniform.
Some frames have a bunch of crap that happens to happen, like incoming
IO, some have none; or some frames might have to upload a texture or
something and then the next 10 frames don't have to do that. It isn't
very predictable. litl shell is a number of different apps plus a
compositing/window manager all crammed into a single process so it may
have had more trouble than most things.

In short we haven't managed to dynamically pick the 5ms number. But
just setting it to 5ms seems to work pretty well.

Another number that we've tried to get clever with but failed is the
frame timestamp used for tweening. You have this correct in your
document of course.  The thing that's tempting is to use actual wall
clock time. But it seems to be true that animations are prettier if
you just add the frame length to it every time, and if the result gets
"too far" (for us, 1 frame) behind the wall clock, skip ahead by whole
frame intervals thus dropping frames. I guess the reason is that vsync
is always going to show the stuff at exact frame intervals, so using
any frame timestamp not on those intervals is just wrong. Anyway this
is one reason why GtkImage animations and the "traditional JavaScript
technique with Date.now()" described in roc's mozRequestAnimationFrame
post are inherently not smooth looking. The lag between generating the
frame and getting it on the screen is enough to make wall clock time
when generating almost irrelevant.

I kinda think "snap wall clock time to multiples of frame_length for
tweening" will look pretty good even if the app has no awareness of
when the vsyncs actually happen, as long as the refresh rate is known
you have a good chance that each of your frames will show up and that
you'll get a different frame on each vsync. For example even in a
non-GL GTK, if GTK queried the refresh rate (e.g.
XRRConfigCurrentRate()) and used that for the paint clock, I bet it
makes GTK animations look way nicer than they do now.

Havoc