Set contents_opaque(false) if the background color is transparent #34930
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
wpt-pr-bot
approved these changes
Jul 21, 2022
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3779000
branch
4 times, most recently
from
85742f8
to
c931b0e
Compare
Previously if a layer's background was transparent and the layer is opaque, we used the layer_tree_host's background as SafeOpaqueBackgroundColor(). One of the usages of SafeOpaqueBackgroundColor() is to fill the otherwise translucent antialiased pixels along the edge of rasterization, when the layer has non-integral raster transform, to ensure the layer is still fully opaque. However, the color might be dramatically different from the normal color in the layer, causing edge artifacts. Now set contents_opaque(false) in the case. The case of opaque layer not having a background color only happens in cases such as the layer has an opaque background image. In such cases, using any heuristic color as the SafeOpaqueBackgroundColor() may be inappropriate because the color may be visibly different from the background image. This also prevents seams between adjacent image layers when the layers layer have non-integral to-screen transforms. Bug: 1330509 Change-Id: I91edeb1c02da5eaa38ea0431f0559775b273f418 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3779000 Reviewed-by: Stefan Zager <szager@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/main@{#1028113}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3779000
branch
from
c931b0e
to
b2b825b
Compare
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.
Previously if a layer's background was transparent and the layer is
opaque, we used the layer_tree_host's background as
SafeOpaqueBackgroundColor(). One of the usages of
SafeOpaqueBackgroundColor() is to fill the otherwise translucent
antialiased pixels along the edge of rasterization, when the layer
has non-integral raster transform, to ensure the layer is still
fully opaque. However, the color might be dramatically
different from the normal color in the layer, causing edge artifacts.
Now set contents_opaque(false) in the case.
The case of opaque layer not having a background color only happens
in cases such as the layer has an opaque background image. In such
cases, using any heuristic color as the
SafeOpaqueBackgroundColor() may be inappropriate because the color
may be visibly different from the background image.
This also prevents seams between adjacent image layers when the layers
layer have non-integral to-screen transforms.
Bug: 1330509
Change-Id: I91edeb1c02da5eaa38ea0431f0559775b273f418
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3779000
Reviewed-by: Stefan Zager <szager@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1028113}