[Webkit-unassigned] [Bug 252648] [GTK] GtkSnapshot contains overly large damage area

[bugzilla-daemon at webkit.org]

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

--- Comment #1 from Adrian Perez <aperez at igalia.com> ---
(In reply to Christian Hergert from comment #0)
> Hi!
> 
> I'm the author of a good portion of GTK 4's GL renderer. I wanted to chime
> in on some implementation details that might allow for improving snapshot
> performance of the GTK WebKitWebView when using EGL.

Hello Christian! Always good to have your input, specially when it comes
to performance issues ��️

> Currently, when using WebKit's accelerated rendering with the GTK 4 backend,
> an EGL texture is imported into GDK and snapshotted.

Indeed, that's how it works under Wayland.

Under X11 we are still using Cairo to paint the texture shared by the
WebProcess, although in theory it should be possible to import it when
backed by a DMA-BUF, or at least paint it on a textured quad to avoid
hitting the (slow) Cairo method. I haven't had the time to bring it into
WebKit, but here we do the textured quad method:

  https://github.com/Igalia/cog/blob/master/platform/x11/cog-platform-x11.c#L152-L177

> The unfortunate bit is that there is no damaged associated with the texture
> (as textures in GDK are considered "immutable"). What that means is when the
> GskRenderNode tree is snapshotted, it will perform a diff to the previous
> frame to determine damage. The single texture node currently added to the
> snapshot will be different, causing the damage rectangle to match the entire
> bounds of the texture area.
> 
> That means if you have a 16x16 GIF animating, you'll still redraw the entire
> browser window as far as the desktop compositor is concerned.
> 
> While I haven't looked to see what texture sharing mechanism is being used
> under the hood, I suspect it's a DMABUF attached to a GL texture? If so, one
> possible way to improve this is to keep 2 textures around (mapped to the
> same DMABUF). If you snapshot as tiles of textures (say 128x128) you only
> need to "flip" the tile which intersects the underlying damage. That is
> enough for "gsk_render_node_diff()" to see the damage.

There are some drivers which can do Wayland but don't necessarily expose
the needed EGL/GLX extensions to export and import DMA-BUFs, which is why
we have a nested Wayland compositor here--mostly a concern for non-Mesa
drivers. We have lately been adding more dependency on DMA-BUF machinery
(e.g. for WebGL2 + GPUProcess) so it may be possible to try and detect at
runtime whether to do something like you suggest =)

> I have some example code doing this in libmks
> https://gitlab.gnome.org/chergert/libmks/-/blob/main/lib/mks-dmabuf-
> paintable.c which could serve as an example.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230221/4fb68f1a/attachment.htm>