When using background-clip with text, the underlying gradient background ignores the color space
Categories
(Core :: Web Painting, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox130 | --- | fixed |
People
(Reporter: julienw, Assigned: jfkthame)
Details
Attachments
(5 files)
STR:
- Open the file.
- Notice that the 2 rectangle gradients are different (as expected) => OK
- Notice that the gradients shaping the text are the same in both cases => KO, the colorspace isn't applied.
Note that this works as expected in Chrome.
Thanks https://pouet.it/@lamecarlate/112802399540427704 for the testcase.
Comment 1•1 year ago
•
|
||
We seem to get it right with SVG gradients FWIW.
Comment 2•1 year ago
|
||
Moving this to the color space component for some eval there. If it is indeed text-related, please bounce it back.
Comment 3•1 year ago
|
||
Julien, can you please capture the output of your about:support to a file and attach it here?
Comment 5•1 year ago
|
||
After consulting, switching this back to Text. Jonathan, would this be in your wheelhouse?
| Assignee | ||
Comment 6•1 year ago
|
||
(In reply to Bob Hood [:bhood] from comment #5)
After consulting, switching this back to
Text. Jonathan, would this be in your wheelhouse?
Not really, I think.... this seems more about display-list/painting operations, not about fonts themselves or text shaping etc. As I understand it, background-clip:text works by using the text to generate a mask in nsDisplayBackgroundImage::PaintInternal. After that, it should just be a case of painting the gradient correctly.
From a bit of poking around, I wonder if nsCSSGradientRenderer lacks support for controlling the color interpolation method when it's not actually painting via webrender? At least, the only user of StyleGradient::ColorInterpolationMethod() appears to be nsCSSGradientRenderer::BuildWebRenderParameters; it's not used in any way in the non-WR nsCSSGradientRenderer::Paint method AFAICS.
I think it would be possible to handle this by interpolating stops around here in nsCSSGradientRenderer::Paint, similarly to what the webrender code path does here. But I wonder if it'd make more sense to do this earlier during nsCSSGradientRenderer construction, e.g. as an addition to the ComputeColorStops utility.
(Switching back to the Color Management component, as the issue (AIUI) is a failure to apply the proper color-space handling when painting the gradient, which isn't a text-specific operation. It happens that background-clip:text causes us to take the non-WR nsCSSGradientRenderer::Paint codepath here, but that might not be the only way to reach this code.)
| Assignee | ||
Comment 7•1 year ago
|
||
I experimented with a patch to nsCSSGradientRenderer::Paint to make it do something similar to the WR and SVG-text painting paths, and this seems to have the expected result here. So I'll post that for consideration, but happy for someone else to take over this if there's a better approach we should take.
| Assignee | ||
Comment 8•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 9•1 year ago
|
||
Comment 10•1 year ago
|
||
Comment 12•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/12127424a2ba
https://hg.mozilla.org/mozilla-central/rev/3e4bc30d6e36
Description
•