On Fri, 7 Mar 2014 14:03:48 +0200 Pekka Paalanen <[email protected]> wrote:
> From: Pekka Paalanen <[email protected]> > > 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
