[Webkit-unassigned] [Bug 166057] [GTK] RequestAnimationFrame ticks at 66 FPS instead of 60 FPS

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > 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: http://stackoverflow.com/q/36888288

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.

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).

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.

-- 
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/20170104/a78895d8/attachment.html>