[Webkit-unassigned] [Bug 161683] [GTK] Clarify frame callbacks behaviour in Wayland compositor

[bugzilla-daemon at webkit.org]

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

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #288124|review?                     |review-
              Flags|                            |

--- Comment #2 from Carlos Garcia Campos <cgarcia at igalia.com> ---
Comment on attachment 288124
  --> https://bugs.webkit.org/attachment.cgi?id=288124
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=288124&action=review

> w/Source/WebKit2/UIProcess/gtk/WaylandCompositor.cpp:237
> +    // From a Wayland point-of-view firing frame callbacks here is very weird,
> +    // but our WebProcess clients don't rely on them for synchronization and
> +    // set the EGL swap interval to zero, relying on the RenderNextFrame events
> +    // in the WebKit IPC instead

The comment adds more confusion to me. It says that the firing frame callbacks here is weird, but it doesn't say why or where they should be fired. The only reason why I didn't remove all frame callbacks handling from the nested compositor is because I was not sure we can rely that eglSwapInterval is always going to work for all drivers. But if it works, frame callbacks are never emitted, so this list is always empty. The reason why we do this, is not because we rely on RenderNextFrame events, adn there isn't any WebKit IPC involved. The reason is that we are rendering to an offscreen context always in the web process, and when we have to render a new frame, we schedule a redraw in the web view, and then we render in the screen. So syncing to vblank in the web process doesn't help, because we will not render at that time to the screen, we will render into the offscreen context, and the  schedule a redraw on the widget. It's at that point where we want to vblank sync, and that's alrea

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