[RFCv3 weston 00/15] Wayland Presentation extension
Pekka Paalanen
ppaalanen at gmail.com
Fri Mar 7 04:03:48 PST 2014
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!
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.
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.
Kristian, patches 1-5 are clean-ups and refactoring to prepare
for the Presentation extension. If you like where this is going,
you could merge those already.
Patch 6 adds the protocol, patches 7 and 9-12 implement the
extension, patches 8 and 13 add clients to test the extensions,
and patch 14 serves as a reminder that I still intend to change
the wl_viewport interface.
Do we want things like patch 15 in Weston?
This whole patch set is available at
http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-RFCv3
git://git.collabora.co.uk/git/user/pq/weston.git presentation-RFCv3
Pekka Paalanen (15):
compositor: refactor more into weston_surface_attach
compositor: buffer can be non-NULL only if newly_attached
compositor: refactor code into weston_surface_reset_pending_buffer()
compositor: reorganize struct weston_buffer_viewport
compositor: replace weston_buffer_viewport::viewport_set
protocol: add presentation extension RFC v3
compositor: add stub implementation of presentation interface
weston-info: report presentation clock
compositor: set and use the presentation clock everywhere
compositor: implement presentation_feedback
compositor-drm: deliver frame seq for feedback
compositor: implement presentation.queue
clients: add presentation-shm demo
protocol: add scaler TODO
compositor: add presentation debug functions
.gitignore | 1 +
Makefile.am | 16 +
clients/presentation-shm.c | 929 +++++++++++++++++++++++++++++++++++++++
clients/weston-info.c | 81 ++++
desktop-shell/shell.c | 6 +-
protocol/presentation_timing.xml | 434 ++++++++++++++++++
protocol/scaler.xml | 4 +
src/compositor-drm.c | 58 ++-
src/compositor-fbdev.c | 12 +-
src/compositor-headless.c | 11 +-
src/compositor-rdp.c | 11 +-
src/compositor-rpi.c | 48 +-
src/compositor-wayland.c | 11 +-
src/compositor-x11.c | 11 +-
src/compositor.c | 861 +++++++++++++++++++++++++++++++++---
src/compositor.h | 70 ++-
src/gl-renderer.c | 2 +-
src/pixman-renderer.c | 26 +-
18 files changed, 2431 insertions(+), 161 deletions(-)
create mode 100644 clients/presentation-shm.c
create mode 100644 protocol/presentation_timing.xml
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?
Thanks,
pq
Btw. this will probably miss the April release of Weston since I
have other projects.
--
1.8.3.2
More information about the wayland-devel
mailing list