[Webkit-unassigned] [Bug 161683] [GTK] Clarify frame callbacks behaviour in Wayland compositor

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=161683

--- Comment #3 from Emanuele Aina <emanuele.aina at collabora.com> ---
Frame callbacks should be fired where you know the compositor has used the committed content. E.g. in Weston it the place where it has queued the GL commands to update the screen and so the next screen update contents have been locked in place.

To be specific, it should not just be any screen update, it should be the particular update that first uses the content from the same commit as where the frame callback was filed. Frame callbacks should also not be fired if the surface is not shown.

What I was trying to say is that despite frame callbacks being the main throttling mechanism in normal Wayland usage, we don't need them for that purpose as throttling is already handled elsewhere by WebKit.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160907/8efd6f4d/attachment.html>