[RFC] wl_surface video protocol extension
frederic.plourde at collabora.co.uk
Thu Oct 17 15:36:12 CEST 2013
> 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
- presentation callbacks (that's currently done by another team at
- 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 :
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 :
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..
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel