Only submit XRGB buffers #53
Open
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
rpigott
approved these changes
Jul 1, 2023
This ensures that the background is always opaque. This is a significant change; before, if no background color was specified, images were drawn onto an initially transparent buffer, leaving some of the content behind swaybg visible if the image was alpha transparent or if the 'fit' or 'center' scaling modes were used and the image aspect ratio did not match, or the image was not large enough. As the purpose of a wallpaper/background program is to draw the pixels behind all other interface items, this transparency is neither a required nor a very useful behavior. The new color is close to the result of blending the old default background color (#00000000 = transparent) with the color Sway uses to clear the background ([0.25,0.25,0.25,1.0] = mid gray). Users of other compositors may need to adjust their images or specify the --color flag on the command line.
This lets the compositor avoid needing to clear and blend the pixels behind the background surface made by swaybg.
|
I've rebased this to a) fix a merge conflict b) update the first commit to ensure that single-pixel-buffers are always opaque. I don't think any other changes made over the last two years would affect this code, but just to be sure this should probably be re-reviewed. |
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.
These two commits resolve #26, by always submitting opaque buffers. This is done by painting the buffers submitted with a uniform color, before drawing the image on top. The default color is chosen to match Sway's default background color, so that most people invoking swaybg under Sway with a semi-transparent (or badly sized
fitorcentermode image) will see the same result as before.I've been undecided about this change for a while, since there is an alternative which preserves the current behavior; to detect when the output image may be semi-transparent, as a function of the scaling mode, the image size, the presence of the
--colorflag, and whether the image has an alpha channel. However, I don't think allowing transparency in edge cases is a good behavior for a wallpaper program to have, and solving #26 while keeping the current behavior makes the buffer creation logic more complicated, making changes like submitting 10-bit buffers -- for which Cairo only supports the opaque RGB30 format -- harder to implement.