Bug 218292 - [GTK] Direct composited images may not be rendered after a window resize
Summary: [GTK] Direct composited images may not be rendered after a window resize
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Miguel Gomez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-28 10:31 PDT by Miguel Gomez
Modified: 2020-10-30 01:40 PDT (History)
7 users (show)

See Also:


Attachments
Patch (5.30 KB, patch)
2020-10-29 01:24 PDT, Miguel Gomez
no flags Details | Formatted Diff | Diff
Patch (5.26 KB, patch)
2020-10-29 09:30 PDT, Miguel Gomez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Miguel Gomez 2020-10-28 10:31:58 PDT
This can be reproduced when there is a directly composited image that's invisible and becomes visible after maximizing the minibrowser window.

What happens here is quite tricky (yet reproducible most of the times):

1 - The resize triggers a call to ThreadedCompositor::setViewportSize(), and this schedules an update.
2 - The resize triggers a call to LayerTreeHost::forceRepaint(), which calls CompositingCoordinator::flushPendingLayerChanges() causing a layer flush.
3 - The layer flush finds that the directly composited image is now visible, renders the content in a buffer, and pass the buffer to the state so it can reach the CoordinatedGraphisScene
4 - On a normal layer flush, the scene grabs the state, updates its values with the new ones, renders, and tells the LayerTreeHost that a new layer flush can be performed (with LayerTreeHost::renderNextFrame). But end of the rendering triggering in 1 will also call LayerTreeHost::renderNextFrame, causing the LayerTreeHost to launch a new layer flush before the scene has grabbed the state contents generated by the last one
5 - The new layer flush, knowing that the buffer for the image was already sent, will send an empty buffer this time (the content was already sent, no need to do it again)
6 - ImageBackingTextureMapperImpl::flushUpdate() will overwrite the previous update with the new one (with the empty buffer). But the previous update was the one containing the valid buffer, which wasn't consumed by the scene yet.
7 - After the layer flush, the new state is passed to the scene, where it will get the new image backing update, which has an empty buffer. This causes that the image won't be rendered.
Comment 1 Miguel Gomez 2020-10-29 01:24:37 PDT
Created attachment 412624 [details]
Patch
Comment 2 Carlos Garcia Campos 2020-10-29 02:17:33 PDT
Comment on attachment 412624 [details]
Patch

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

> Source/WebCore/platform/graphics/nicosia/texmap/NicosiaImageBackingTextureMapperImpl.cpp:55
> +        m_update.update.isVisible =  m_layerState.update.isVisible;

There's an extra space after the =
Comment 3 Miguel Gomez 2020-10-29 09:30:37 PDT
Created attachment 412660 [details]
Patch
Comment 4 EWS 2020-10-30 01:40:18 PDT
Committed r269179: <https://trac.webkit.org/changeset/269179>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 412660 [details].