Re: Doubts about GPeriodic

[Owen Taylor <otaylor redhat com>]

[ Reply abbreviated to a couple of topics where I had firmer answers ]

On Sat, 2010-10-23 at 17:42 -0400, Havoc Pennington wrote:

> On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor <otaylor redhat com> wrote:
> >  - We should not start painting the next frame until we are notified
> >   the last frame is complete.
> 
> Does frame-complete arrive when "we just did the vsync" i.e. last
> frame is just now on the screen?
> 
> We can dispatch "other stuff" while we wait for this, right? Does the
> time between sending off the buffer swap, and getting the frame
> complete back, count as time spent doing other stuff? I guess that
> would roughly mean "if paint finishes earlier than it had to, get
> ahead on other stuff in the meantime" - the wait-for-frame-complete is
> a way to take advantage of any time in the 50% designated for painting
> that we didn't need.
> 
> I mean, presumably while waiting for frame-complete the main loop is
> going to run, the question is just whether that time gap factors into
> any of the time calculations.

The time between when we finish the frame and the we receive frame
complete is some unknowable mix of:

 - CPU time in the kernel validating render buffers
   (or in a indirect rendering X server, I suppose)
 - Time waiting for the GPU to finish
 - Time until VBlank occurs

Only the first is conceivably something we want to balance with "other
stuff", and even that is likely running on another core these days and
more so in the future.

So, what we are trying to balance here is:

 A) The time in event-processing, animation update, layout, and paint
    up to the point we call glXSwapBuffers() (or XCopyArea() in the X
    case)
 B) The time we spend processing other stuff from the point where
    we called glXSwapBuffers()

[...]

> > So, there's some appeal to actually base it on measured frame times.
> > Using just the last frame time is not a reliable measure, since frame
> > painting times (using "painting" to include event process and relayout)
> > are very spiky. Something like:
> 
> I had awful luck with this. (I did try the averaging over a window of
> a few frames. I didn't try minimum.)
> It's just really lumpy. Say you're transitioning from one screen to
> another, on the first frame maybe you're laying out the new screen and
> uploading some textures for it, and then you have potentially very
> different repaint times for the original screen alone, both screens at
> once during transition, and the final screen. And especially on crappy
> hardware, maybe you only get a few frames in the whole animation to
> begin with. Minimum might be more stable than average. Another issue
> with animation is you don't know the average until you're well into
> the animation

For the purposes of balancing, it doesn't matter if we have an accurate
estimate. If the animation has more complexity and takes longer to paint
than the pre-animation state, that means we're just balancing a bit more
toward animation than in the pre-animation state until we get new
statistics. (I don't think animations typically have *reduced*
complexity, because the animation have a mixture of pre-animation GUI
elements and post-animation GUI elements.)

What we don't want is to be thrown way off - if the first animation
frame takes 100ms to layout because we have a bunch of new text to
measure, we don't want to eat another 100ms doing background processing.
This is why I suggested a minimum over several frames. (Or detecting
"first frames" by looking for keystrokes and button presses.)

- Owen