[PATCH] Add presentation_time and hit requests to wl_surface.

[Pekka Paalanen]

On Mon, 4 Nov 2013 18:21:27 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> Hi Axel,
> 
> I agree with the clock comments, in that we need to know which clock to
> use, and 32 bits may be too short. If we follow struct timespec,
> uint32_t seconds + uint32_t nanoseconds should be fine. We don't have
> 64-bit integers in the protocol.
> 
> How about adding an event which tells the client, which clock the
> compositor is using?
> 
> We cannot simply require CLOCK_MONOTONIC_RAW or CLOCK_MONOTONIC_COARSE,
> because they are Linux-specific and introduced in 2.6.28 and 2.6.32,
> respectively. The clock name should probably be platform-dependant, if
> POSIX values are not enough, so e.g. weston could use
> CLOCK_MONOTONIC_RAW, or whatever is the most appropriate, and on other
> OSs use what's appropriate there.
> 
> More below...
> 
> On Sun,  3 Nov 2013 00:39:58 +0100
> Axel Davy <axel.davy at ens.fr> wrote:
> 
> > These two new requests are designed to help video players
> > to synchronize what is displayed on the screen and the audio,
> > and to implement the X Present extension in XWayland.
> > ---
> >  protocol/wayland.xml | 70 +++++++++++++++++++++++++++++++++++++++++++++++++---
> >  1 file changed, 67 insertions(+), 3 deletions(-)

...

> So, this proposal requires *all* compositors to implement presentation
> timestamping and frame queues for wl_surfaces. And I really mean ALL
> compositors, including any session switchers, system compositors,
> embedded compositors, compositors nested in web-brosers for
> each-tab-is-a-separate-process...
> 
> I think that is a bit much. Extending wl_surface like this does not
> allow a compositor to not implement all this. This is also a bit risky
> in case we ever need to change this interface.
> 
> Therefore I would really prefer the separate interface design, where
> you would also have a natural place to put the what-clock-to-use event.

I just realized one big downside the separate interface design would
have: you would not be able to queue buffers via EGL. EGL will
internally only bash the wl_surface interface.

Still, I'm not yet sold for extending wl_surface for this...

OTOH, would any EGL implementation cope with it, if an app started
queueing frames instead of the usual simple double-buffering? There is
no way for an app to know how many buffers EGL will allocate before it
decides to wait for earlier ones to be released. Would this even be
useful with EGL, considering the app cannot manage the buffers anyway?

Are there any EGL extensions for defining a presentation time?


Thanks,
pq