hwcomposer: Use dummy buffer as window background in subsurface mode #12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aleasto
approved these changes
Aug 22, 2022
|
Rebased and fixed. This MR doesn't depend on #22, I just messed it up when splitting things out. |
HWC assumes that there's an implicit solid black layer below all the other layers to compose onto. Since we already have a dummy buffer attached to the xdg-toplevel surface, it can be used to provide that background in single window mode, which fixes some apps having transparent background in unexpected places. Thanks to wp_viewporter, the buffer can still be just a single pixel, which gets upscaled to cover the whole window by the compositor. Since multi window mode relies on the background being transparent, keep it that way there by allowing to specify window background color in create_window.
When the background is transparent, we don't want it to consume any input events. Similarly, when the background is fully opaque, we know that the whole surface is opaque too, so we can mark it as such to allow the Wayland compositor to optimize its drawing.
|
@dos1 looks like the ubports compositor doesn't implement viewporter so this (as well as your other changes involving the viewporter) breaks compositing there... |
|
Ah, yeah. Any reasonably modern compositor should already support viewports, but well, UBport's Mir sure doesn't qualify to such title... Won't be a big deal though, it's just a matter of sprinkling stuff with bunch of ifs. Of course crops will stay broken on such compositors, but at least the background can still be provided by creating a full-sized buffer instead. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
HWC assumes that there's an implicit solid black layer below all the other layers to compose onto. Since we already have a dummy buffer attached to the xdg-toplevel surface, it can be used to provide that background in single window mode, which fixes some apps having transparent background in unexpected places. Thanks to wp_viewporter, the buffer can still be just a single pixel, which gets upscaled to cover the whole window by the compositor.
Since multi window mode relies on the background being transparent, keep it that way there by allowing to specify window background color in create_window.
When the background is transparent, we don't want it to consume any input events.
Similarly, when the background is fully opaque, we know that the whole surface is opaque too, so we can mark it as such to allow the Wayland compositor to optimize its drawing.
Also, don't leak the dummy wl_buffer on window destroy.