[RFCv3 weston 00/15] Wayland Presentation extension

[Pekka Paalanen]

On Fri,  7 Mar 2014 14:03:48 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> 
> Hi all,
> 
> here is the third RFC of the Wayland Presentation protocol, now
> with a complete implementation!

Hi all,

I have rebased the RFCv3 version on top of the current Weston master,
and added a few fix commits. This is for anyone who would like to check
it out before I get around to posting RFCv4 (no idea when that will be).

You can find the rebased series at
http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-WIP3
which I force-pushed just now.

Note, that this series cannot get out of the RFC status before
https://bugs.freedesktop.org/show_bug.cgi?id=78190
has been solved and implemented.

> RFCv2 can be found at
> http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html
> and the email thread contains extensive discussion, from which
> the conclusions have been implemented. Let me know, if I missed
> something.
> 
> The changes to the protocol itself are listed in patch 6/15. I
> have not forgot about the new features listed in
> http://cgit.collabora.com/git/user/pq/weston.git/tree/buffer-queue3.txt?h=buffer-queue-spec
> and I intend to write a protocol patch to get the discussion
> about those started.

That patch was sent as:
http://lists.freedesktop.org/archives/wayland-devel/2014-March/013598.html

As the patch breaks the build because it lacks all the code changes, it
is not part of the rebased series at this time.

> The impact to the Wayland core protocol still exists, but is
> mitigated by the fact that frame callbacks are no longer queued,
> and hence whether there is an attach or not does not affect the
> processing of frame callbacks on commit.
> 
> Still, doing an immediate commit without a preceding
> wl_surface.attach is defined to work differently than in the
> core: the buffer state will not be applied without an attach.
> IOW, you cannot change e.g. buffer_scale without attaching a
> wl_buffer. In my opinion, the newly disabled actions did not make
> sense in the first place, but it is still a change to the core
> protocol.
> 

> Here are some examples of weston-presentation-shm statistics
> output on Weston on DRM with gl-renderer. See patch 13 for more
> details.
> 
> Mode -f, feedback from frame callback driven immediate commit
> loop:
> 
>      7: f2c  1 ms, c2p 32 ms, f2p 33 ms, p2p 16648 us, t2p 32670, seq 7741506
>      8: f2c  0 ms, c2p 33 ms, f2p 33 ms, p2p 16650 us, t2p 32677, seq 7741507
>      9: f2c  1 ms, c2p 33 ms, f2p 34 ms, p2p 16652 us, t2p 32671, seq 7741508
>     10: f2c  1 ms, c2p 32 ms, f2p 33 ms, p2p 16648 us, t2p 32700, seq 7741509
>     11: f2c  0 ms, c2p 33 ms, f2p 33 ms, p2p 16651 us, t2p 32680, seq 7741510
> 
> 
> Mode -q, queueing with feedback for every frame, random
> committing order:
> 
>    172: c2p   32 ms, p2p 16650 us, t2p   -30 us, seq 7742478
>    130: c2p   50 ms, p2p 16652 us, t2p   -43 us, seq 7742479
>    133: c2p   67 ms, p2p 16651 us, t2p   -56 us, seq 7742480
>    151: c2p   83 ms, p2p 16656 us, t2p   -65 us, seq 7742481
>    166: c2p   99 ms, p2p 16642 us, t2p   -88 us, seq 7742482
>    177: c2p  115 ms, p2p 16652 us, t2p  -101 us, seq 7742483
>    174: c2p  132 ms, p2p 16648 us, t2p  -117 us, seq 7742484
>    159: c2p  150 ms, p2p 16651 us, t2p  -131 us, seq 7742485
>    148: c2p  166 ms, p2p 16651 us, t2p  -145 us, seq 7742486
> 
> Note, that the refresh period is taken as 1/refresh_frequency,
> which becomes 16666 us, but the actual measured period is
> slightly less on my machine. Since weston-presentation-shm does
> not continuously correct for the drift, you see that the
> difference between the target timestamp and realized presentation
> grows. Still, it would take quite a long time to start missing
> the correct refresh cycle.
> 
> The chosen timing algorithm in the protocol aims to achieve
> t2p = 0 by default and on "average", rather than t2p = half of
> refresh period. An explanation of the timing algorithm and a
> diagram can be found at
> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013182.html
> 
> Some of the interactions between resizing, queueing, sub-surfaces,
> and wl_viewport have been discussed in
> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013293.html
> but that still needs verification by a running demo program.
> 
> I think we should start dicussing, how do we want the protocol
> interfaces to be designed. Do we want a global method with
> wl_surface as an argument (as in this implementation), the
> factory approach like wl_scaler/wl_viewport etc., or something
> else?

Also a reminder about the above question.


Thanks,
pq