[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 #6 from Zan Dobersek <zan at falconsigh.net> ---
(In reply to comment #5)
> (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.
> 

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.

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

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