[RFC] wl_surface video protocol extension

[Frederic Plourde]

>     Plus of course the same for the next buffer, so you know e.g. how long
>     a buffer was on screen etc.
>
>     How does that sound?
>
> So, the information you propose, with timestamps, gives us timestamps 
> from events in the past.
> Is there any way to deterministically ensure that a particular frame 
> is displayed at a particular scanout that we would decide on in advance.
> The problem is, if I timestamp a frame for time X and the scan out 
> actually happens as time X - 1 microsecond, I really wanted not to 
> miss that scanout.
> It would be easier to be able to specify a particular scanout.
>
Hi James, I understand your question, but pinopointing a particular 
scanout makes less sense, as Pekka said, in the case where monitor 
refresh rate can change without notice.
I guess in that case, you'd probably miss your "expected" scanout and 
present the buffer on the next vsync, but remember, you can't know in 
advance when that scanout is going to happen.

So just to summarize what we've got so far :

    - pre-submission timing (queueing buffers with expected presentation 
times)
    - presentation callbacks (that's currently done by another team at 
Collabora)
    - Output refresh rate change/adaptation notification back to clients 
(we'll be working on that soon)

    and, as Pekka said, I'm kinda in favor of keeping "higher-level 
info", like latency predictors for any higher-lever library API on top 
of what we're doing now.
    What do you think ?

>
> > So, I would propose the following.
> > 1) sequence number the frames at the display rate.
> > 2) provide an api for the application to predict the time of each frame
> > number in the sequence. I.e The next 5 frames will display at time
> > X1,X2,X3,X4,X5. Also provide a way to determine the "frame submited to
> > frame displayed" latency. So the user application knows how many 
> frames in
> > advance it needs to do the submit.
> > 3) provide an api for the application to ensure that a frame it submits
> > will get displayed at display rate sequence number X.
> > 4) If frame X has already past, only display it if there are now newer
> > frames in the quene, otherwise drop it.

About that point #4 here, I've already started to work on the 
implementation bits, and I was thinking about doing it like this :

See, at time T=100, for example, if there's this in the queue :

   buffer1,T=75
   buffer2,T=99
   buffer3,T=110

The compositor will  drop buffer1 and present buffer2 right away since 
buffer2 it's the most recent "past" buffers...

And looking at your suggestion #4, if we're having this at time T=112 :

   buffer3,T=110

I don't see why we should drop buffer3 instead of displaying it (we have 
no newer frames in the queue... but we definitely want to display 
something, right ?)
Any clarifications here could be very enlightning..

Cheers :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131017/0ab5db79/attachment.html>