Re: Partial frame synchronization TODO

[Owen Taylor <otaylor redhat com>]

On Thu, 2012-10-04 at 07:38 +0100, jcupitt gmail com wrote:
> This all sounds fantastic, but I have a stupid question:
> 
> On Thursday, October 4, 2012, Owen Taylor wrote:
>         * When there is a frame where no painting ends up being done, we still
>           at the moment are sending increments to the frame serial and waiting
>           for_NET_WM_FRAME_DONE. It may be worth tracking when we are about to
>           damage a toplevel window (by drawing or configuring it) and only at
>           that point start a frame. Then we'll avoid asking the compositor to
>           tell us when it's done painting a frame that involves no painting.
>  
> Does this mean we have a busy idle? Does this have implications for
> laptop battery life? 

What this is about is the case when there is an "animation" that isn't
actually doing something - for example if the application creates a
GtkTimeline, doesn't connect anything to it, and starts it running.

Without compositor synchronization, what we'll do is update the timeline
at 60fps.

When there is a compositor, we assume that the compositor knows better
than us about the frame rate, so we don't throttle to an arbitrary
60fps, but instead wait for the _NET_WM_FRAME_DONE before the next
frame.

If we start a frame, do nothing, and end it, it's possible that the
compositor will immediately send us _NET_WM_FRAME_DONE. So we're at the
mercy of the compositor - we might have a "busy idle" or might not.
The idea of this TODO item is to detect the situation at our end and
fall back to the default 60fps.

But hopefully, applications won't be adding empty animations very often.

- Owen