[Webkit-unassigned] [Bug 265990] New: [GTK][WPE] Random incorrect image displayed as the background of a div

[bugzilla-daemon at webkit.org]

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

            Bug ID: 265990
           Summary: [GTK][WPE] Random incorrect image displayed as the
                    background of a div
           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 can only be reproduced in situations where the MemoryCache if filled and MemoryCache::pruneLiveResourcesToSize() gets called. In order to easily force this, you can edit the function calculateMemoryCacheSizes in CacheModel.cpp so that for the PrimaryBrowser case, the cache capacity is set to 16MB.
Then, loading https://widgets.metrological.com/lightning/liberty/2e3c4fc22f0d35e3eb7fdb47eb7d4658#app:com.gametree.tv.Solitaire will take you to a page with a keypad dialog that is showing an incorrect background image for the dialog (it should be a gray background, but some other image will be shown).

What happens is:

- During a layerFlush, the background images are painted into a buffer that is later passed to the composition, where it's uploaded to a texture to be painted. There are cases where the same image is used as the background of several layers, so instead of painting the image in several different buffers, the CompositingCoordinator keeps a hashMap of ImageBackingStore instances, which contain the rendered buffer for that image, indexed by the nativeImageID (the pointer to the cairo surface that's rendered there). Thanks to this, the layers using the same image as background will have references to the same ImageBackingStore instead of having several buffers with the same content.

- The CompositingCoordinator keeps the ImageBackingStore instances cached until it's the only one with references to them, which means they are not used anymore for the composition.

- In between layer flushes, there's the possibility that the MemoryCache is filled and MemoryCache::pruneLiveResourcesToSize() is called. This may delete the decoded frames for some of the images that we're using. If this happens, when we try to get the nativeImageID of an Image, a new frame will be allocated with a new cairo surface, so we will get a new nativeImageID during the next layerFlush. 

- This causes the ids used by the CompositingCoordinator to index the ImageBackingStore hashMap to become obsolete, as the content is in a different cairo surface now, and the nativeImageID is different. So when we try to get the ImageBackingStore for a nativeImageID, it won't be in the hashMap and a new one will be created for that nativeImageID.

- This wouldn't be a problem if it wasn't because, after calling MemoryCache::pruneLiveResourcesToSize(), new cairo surfaces allocated for the images may be allocated in the same address than previous ones. This is what happens in the example provided. The new nativeImageID gotten for one of the images is the same that another image had before the call to MemoryCache::pruneLiveResourcesToSize(). Due to this, instead of getting a new ImageBackingStore from the CompositingCoordinator, we're getting one that was used by a different image before, which has the wrong image. So when we render that layer, we're using an incorrect ImageBackingStore and the content shown is not appropriate.

After giving a look, I think the best way to fix this is to clear the CompositingCoordinator's hashMap after each layer flush, as can't guarantee that the nativeImageIDs that it holds are valid for subsequent layer flushes if MemoryCache::pruneLiveResourcesToSize() is called.

-- 
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/20231207/5c34f67b/attachment.htm>