GNOME Bugzilla – Bug 698864
wayland: improve integration with GdkFrameClock
Last modified: 2013-04-25 17:57:19 UTC
Here are some patches to implement synchronization and presentation timestamps. The presentation timestamp handling is a bit of a hack, in that it depends on Weston specifics, rather than anything specified in the protocol.
Created attachment 242433 [details] [review] GdkWindowWayland: draw, then damage, then commit When exposing an area, we were individually damaging and committing each rectangle, *before* drawing. Surprisingly, this almost worked. Order things right and only commit once.
Created attachment 242434 [details] [review] GdkWindowWayland: make sure we attach the surface when repainting Lazily creating the cairo surface that backs a window when we first paint to it means that the call to gdk_wayland_window_attach_image() in gdk_wayland_window_process_updates_recurse() wasn't working the first time a window was painted.
Created attachment 242435 [details] [review] GdkWaylandWindow: synchronize frame drawing Use wl_surface_frame() to get notification when the compositor paints a frame, and use this to throttle drawing to the compositor's refresh cycle.
Created attachment 242436 [details] [review] GdkWaylandWindow: Consolidate surface creation and destruction code Combine duplicate code for creating and destroying surfaces. To make the operatin of the destroy() operation more obvious, the destruction of the (fake) root window at display dispose time is changed to not be a "foreign" destroy.
Created attachment 242437 [details] [review] wayland: fill in refresh_interval in GdkFrameTimings Track the outputs that a window is on, and use the refresh rate from a random one of those outputs for the refresh_interval in GdkFrameTimings.
Created attachment 242438 [details] [review] wayland: when possible, fill in actual and predicted presentation times There is currently no Wayland protocol for providing presentation timestamps or hints about when drawing will be presented onscreen. However, by assuming the straightforward algorithm used by the DRM backend to Weston, we can reverse engineer the right values.
Review of attachment 242433 [details] [review]: Good fix.
Review of attachment 242434 [details] [review]: This looks good - these code paths were a bit clunky following the removal of the cairo-gl code. So nice to see them cleaned up.
Review of attachment 242436 [details] [review]: Just a small typo in the commit message. But this looks good otherwise.
Review of attachment 242437 [details] [review]: Yeh. Looks good. Shows we might need to think about how we convey the window area per output in future wayland protocol enhancements.
Review of attachment 242438 [details] [review]: It looks good to me. I'm not going to claim I follow it 100% but I think the code matches the comment :-) ::: gdk/wayland/gdkwindow-wayland.c @@ +270,3 @@ + /* The timestamp in a wayland frame is a msec time value that in some + * way reflects the time at which the server started drawing the frame. + * This is not useful from out perspective. small typo
Review of attachment 242435 [details] [review]: You're the expert on the GdkFrameClock bits .. all the wayland bits look good though.
Patches pushd (with the two typo fixes), thanks for the review. Attachment 242433 [details] pushed as d5310f9 - GdkWindowWayland: draw, then damage, then commit Attachment 242434 [details] pushed as c71fea5 - GdkWindowWayland: make sure we attach the surface when repainting Attachment 242435 [details] pushed as ca120a9 - GdkWaylandWindow: synchronize frame drawing Attachment 242436 [details] pushed as f1ce727 - GdkWaylandWindow: Consolidate surface creation and destruction code Attachment 242437 [details] pushed as 23031de - wayland: fill in refresh_interval in GdkFrameTimings Attachment 242438 [details] pushed as b72cf91 - wayland: when possible, fill in actual and predicted presentation times
*** Bug 695500 has been marked as a duplicate of this bug. ***