<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Clarify frame callbacks behaviour in Wayland compositor"
href="https://bugs.webkit.org/show_bug.cgi?id=161683#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Clarify frame callbacks behaviour in Wayland compositor"
href="https://bugs.webkit.org/show_bug.cgi?id=161683">bug 161683</a>
from <span class="vcard"><a class="email" href="mailto:emanuele.aina@collabora.com" title="Emanuele Aina <emanuele.aina@collabora.com>"> <span class="fn">Emanuele Aina</span></a>
</span></b>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>