[Webkit-unassigned] [Bug 242394] New: [GTK][WPE] Memory usage regression handling imageBackings since moved to nicosia

[bugzilla-daemon at webkit.org]

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

            Bug ID: 242394
           Summary: [GTK][WPE] Memory usage regression handling
                    imageBackings since moved to nicosia
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: magomez at igalia.com
                CC: bugs-noreply at webkitgtk.org

This was reported downstream for 2.28 but it's happening on upstream ToT as well.

Before we switched to use nicosia, several CoordinatedGraphicsLayers that would be using the same image as imageBacking would share the same buffer with the image content. This way we would only render and send to the composition stage a single buffer, and all the TextureMapperLayers would use it during the composition.

But with the current implementation using nicosia this doesn't happen anymore. Each CoordinatedGraphicsLayer will use its own buffer containing the image as the imageBacking. Due to this, several buffers with the same image will be created and passed to the composition stage, increasing the used memory a lot.

There's a very common scenario when an application uses a very big image that contains several smaller images (sprites), and the application will, for example, set parts of that big image as the background for several divs, so each div shows one of the sprites. If those divs have their own GraphicsLayer (because of hw acceleration reasons), before nicosia there would be a single buffer containing the big image and that would be used by all the GraphicsLayers. But nowadays each layer will use a buffer containing the big image, which is a waste of memory. Also this happens at the same time we're rendering the backingStore contents, so we are already at point where the memory usage is high, potentially triggering oom kills for the excessive memory consumption.

This happens if you visit https://sky.play.works/service/apps/portal/index.html. After the initial page with the loading progress bar, a page with the list of games is shown. All of the game covers are stored in a single image with size 1409x986, and each game shown is a div with part of that image as the background. In this case, the large image with all the covers is rendered into more than 20 buffers, creating a huge memory spike that should not be necessary. (be sure to maximize the browser window before loading the page, otherwise for some reason the images loaded will be smaller).

We should implement back some system to share imageBackings buffers among the CoordinatedGraphicsLayers that are using the same image to avoid this.

-- 
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/20220706/404a1dd0/attachment.htm>