<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#c7">Comment # 7</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:clopez@igalia.com" title="Carlos Alberto Lopez Perez <clopez@igalia.com>"> <span class="fn">Carlos Alberto Lopez Perez</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=166057#c6">comment #6</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=166057#c5">comment #5</a>)
> > (In reply to <a href="show_bug.cgi?id=166057#c4">comment #4</a>)
> > > (In reply to <a href="show_bug.cgi?id=166057#c3">comment #3</a>)
> > > > (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.
> > >
> > > 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.
> >
> > I got that info from this thread: <a href="http://stackoverflow.com/q/36888288">http://stackoverflow.com/q/36888288</a>
> >
> > In our use case (with the threaded compositor) I think that we don't call
> > glXSwapBuffers() all the time, but only when we have new content to show.
> >
>
> When there's nothing to update, we don't.
>
> > But a DisplayRefreshMonitor should send an event notification every time a
> > vsync happens on the monitor (even if we don't have nothing new to show on
> > the screen).
> >
>
> Why? I see no reason for that.</span >
I was not taking into account that what the page schedules during a rAF callback should trigger new content to be shown, hence a new call to glxswapbuffers().
So, maybe it works.
However, I'm a bit wary that this may break some webpage that (incorrectly) expects rAF to trigger at 60FPS always, and uses this callback to schedule calculations that don't necessarily trigger an update of the webview (like the fps-counter example i posted at the top.. it only updates the page every second and not on every rAF callback... with this idea i would be measuring 1-2FPS)
Chrome seems to tick always at 60FPS (and also firefox). They throttle the rAF timer when the webview is not focused.
<span class="quote">>
> > So, perhaps a way to achieve that in X11 is a dummy thread doing all the
> > time dummy glXSwapBuffers();glFinish(); calls, with the hope that this calls
> > will be throttled to the display refresh rate.
>
> Then you need a whole additional context just for that thread.</span >
Yes.</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>