[RFCv3.1 weston] WIP protocol: add flags and refresh stream to presentation

[Mario Kleiner]

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
>>> http://cgit.collabora.com/git/user/pq/weston.git/tree/buffer-queue3.txt?h=buffer-queue-spec
>>>
>>> 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
>> missed.
>>
>> 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.

thanks,
-mario