Incorrect opaque regions on first commit after resize on Wayland
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: contact, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
33.40 KB,
text/x-log
|
Details |
Steps to reproduce:
My own Wayland compositor has a view where all windows are temporarily frozen, only allowing updates when the window is resized and only applying the first commit after the resize.
This issue can be reproduced by shrinking Firefox, applying the first commit, then ignoring all the commits that come after it.
Actual results:
Firefox seems to have two surfaces on Wayland, one being seemingly transparent while the other contains the actual useful window data. However both are reported as transparent.
On the first commit after the resize, the "invisible" surface seems to be resized already while the actual surface is not resized yet, causing damage tracking to break since the invisible surface claims full opacity but it cannot rely on the main surface clearing its opaque region and it's not actually opaque.
Expected results:
The transparent surface probably shouldn't be marked as fully opaque. Alternatively both surfaces should be synchronized to ensure they're resized at the same commit.
I have tried setting widget.wayland.opaque-region.enabled to false, but Firefox still sets both surfaces to be fully opaque. So the setting seems to have no effect (which maybe should be a second, separate bug?).
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Description
•