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

[Keith Packard]

Owen Taylor <otaylor at redhat.com> writes:

> 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.

Maybe you don't quite understand this change?

> 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.

Let me explain what I've done and see if that will help your current
situation.

Right now, a redirected application that calls PresentPixmap will have
that presentation delayed until the scheduled frame. So, an application
which is 'keeping up' (presenting contents very soon after top-of-frame)
will have their new contents waiting around until the next frame begins,
at which point they will be copied to the redirected pixmap and damage
delivered to the compositor.

The change is to copy the contents immediately, send the damage to the
compositor, and delay sending the PresentNotify event to the client
until the start of the next frame.

So, if an application manages to present a new frame in the 2ms after
vblank, the change will get that up on the screen a full frame earlier.

> 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:

You can "edit" the queued operation with the Present API. Current kernel
drivers can't do this with page flipping, but if you force a copy, then
you can replace that pending operation with another copy at any point.

If you're doing sub-region updates by copying portions of windows to the
current scan-out buffer, then you can queue as many as you want for a
particular frame, and all of them will get executed at vblank time. If
one of the queued requests subsumes an existing request, the previous
request will be skipped.

> 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.

If the damage appears before you draw the next frame, I think it'll help.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150126/4275507d/attachment-0001.sig>