[PATCH 0/3] present: Improve interactions with compositing manager

[Owen Taylor]

On Sat, 2014-12-13 at 00:32 -0800, Keith Packard wrote:
> Here's a short patch series which reduces lag when using PresentPixmap
> with a compositing manager. I wrote up a short description on my blog:
> 
> 	http://keithp.com/blogs/present-compositor/
> 
> The basic idea is to perform the CopyArea immediately upon receipt of
> the PresentPixmap request, but to delay the PresentComplete event
> until the actual vblank occurs, allowing the compositing manager a
> chance to actually get the contents onto the screen at the desired
> time.

Hi Keith -

Sorry for getting to this so slowly. At least for the algorithms that
GNOME currently uses, this isn't going to help avoid the extra frame of
latency.

It would potentially work if the compositor drew the frame to the screen
immediately upon receiving damage, but this algorithm tends to result in
uneven jerky updates if there is more than one application drawing - the
first application to draw "wins" and the next app gets delayed a frame.

What we do instead start drawing the frame at a fixed point in the frame
cycle. The point isn't chosen "as late as possible", since that's hard
to predict reliably - after all, we can get damage events for drawing
that isn't even completed on the GPU (at least we could with DRI2) - but
rather is fixed to an arbitrary point 2 ms after VBlank. The idea here
is to accept the extra frame of latency and within that constraint make
things as predictable and as smooth as possible.

I think to get rid of the extra frame of latency, you need to be able 
"edit" a queued presentation in some fashion. If the compositor could
put the active window into a separate hardware overlay then it would be
easy. But it might be possible to just present another buffer:

 - Copy queued buffer to a new buffer
 - Overwrite with the updated window image
 - Present that for the same timestamp as the last frame

It doesn't scale to *arbitrarily* many updating apps, but it could fix
the case where one app is trying to draw smoothly, and another app jumps
in and blinks the cursor. It wouldn't even (I think) require any new API
beyond the current Present extension, but it would require more
consistency in the X driver world than currently exists to make it
worthwhile as more than just an experiment.

Does it *hurt* to make the change you are proposing? Not that I can
think of - there's no downside to getting the damage early, even if we
don't use it, and the PresentComplete timestamps would only be as
inaccurate as they already are.

- Owen