[RFCv3.1 weston] WIP protocol: add flags and refresh stream to presentation
mario.kleiner.de at gmail.com
Wed Mar 26 10:50:29 PDT 2014
On 03/26/2014 03:32 PM, Pekka Paalanen wrote:
> On Tue, 25 Mar 2014 19:47:21 +0100
> Mario Kleiner <mario.kleiner.de at gmail.com> wrote:
>> On 03/07/2014 04:09 PM, Pekka Paalanen wrote:
>>> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>>> This is quick write-up of
>>> How would this idea feel?
>> Hi Pekka,
>> looks good to me. Should serve the needs of my type of application.
> Hi Mario,
> nice to hear that. :-)
>> One possible extension for the queueing flags would be to have a "target
>> presentation timestamp is relative to previous queued update" flag. It
>> would mean that a given target presentation timestamp is not in absolute
>> time, but relative to the realized presentation time of the previous
>> queued update. This would allow to retain the relative spacing of
>> presented frames for an application that queues a bunch of frames as
>> part of an animation, even if some frames target presentation time is
>> E.g., for a movie/animation playing at 30 fps ~ 0.033333 seconds per
>> frame, one could queue the start frame of the movie at an absolute
>> target time, but then queue all following frames as having a relative
>> timestamp of 0.033333 seconds wrt. to presentation of previous frames.
>> Otoh this adds more complexity, so this is just a thought for a possible
>> future extension.
> What should happen if we still need to discard queued updates? E.g. if
> previous realized presentation time + delta from the next queued update
> is already out of reach, maybe due to too small delta or determining the
> realized timestamp too late. Should the delta be defined as the minimum
> time difference and imply no_skip?
I'm not sure if it should enforce no_skip, but i think the typical use
case would set no_skip.
> Yeah, this can very well be left for the future in case a use case
> comes up, it would not need changes to existing protocol, just
> additions AFAICT.
Yes, just an extension, no change to existing protocol. I also think it
should be left for the future, not for the initial protocol. Just a
half-finished thought i had.
>> Fwiw, I also took a few hours to go through your RFC v3 patch series and
>> "sort of" review patches 6-12 and 15. I'm not familiar enough with
>> Weston yet, but i couldn't find obvious bugs and the implementation of
>> the bits i do understand looks correct, e.g., the method/implementation
>> of picking updates from the queue for presentation, sending presentation
>> feedback, the drm/kms stuff etc. To me this looks good so far.
> Thank you! Very much! :-)
> Would you like me to add a reviewed-by tag for you to some patches?
It probably can't hurt, so if you want to, yes. I'll try to give your
stuff some good testing once i get around to actually install Weston and
play with it, but could be a couple of weeks before i find the time.
More information about the wayland-devel