<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] RequestAnimationFrame ticks at 66 FPS instead of 60 FPS"
href="https://bugs.webkit.org/show_bug.cgi?id=166057#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] RequestAnimationFrame ticks at 66 FPS instead of 60 FPS"
href="https://bugs.webkit.org/show_bug.cgi?id=166057">bug 166057</a>
from <span class="vcard"><a class="email" href="mailto:zan@falconsigh.net" title="Zan Dobersek <zan@falconsigh.net>"> <span class="fn">Zan Dobersek</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=166057#c3">comment #3</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=166057#c2">comment #2</a>)
> > I looked into using DisplayRefreshMonitor for the GTK port, specifically in
> > the ThreadedCompositor. The problem is that when using GLX, there's no
> > facility available that could send a notification about the vsync event from
> > the UIProcess down to the WebProcess. With Wayland there's frame callbacks.
>
> Some people suggest to use a separate thread doing glXSwapBuffers();
> glFinish(); all the time after setting glXSwapIntervalEXT(1) (which should
> cause the glXSwapBuffers call to be synced with vsync) and then notify the
> main thread about the vsync events.
>
> But I doubt this will be a good idea from a performance-related point of
> view.</span >
I don't know the specifics of those suggestions, but it's maybe similar to what we do with the threaded compositor? GL operations are done on a separate thread, and this DisplayRefreshMonitor would be dispatching the event on the main thread so that it can be signalled to the Web content as well.</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>