1616444 - named colors are color managed differently, depending on layerization & other factors (With gfx.color_management.mode = 1)

Status: VERIFIED FIXED

(Core :: Graphics: Color Management, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Set about:config pref gfx.color_management.mode to 1, and restart Firefox.
2. Load attached testcase

EXPECTED RESULTS:
Each row should be a consistent solid color, all the way across.

ACTUAL RESULTS:
In each row, swatches A and C are a different color than the rest of the swatches.

I think swatches A and C are the only ones that we're drawing with color management. They seem to match the color that Chrome uses for the whole row. The other swatches look brighter in Firefox as compared to Chrome (on my machine at least). So I think all of those other swatches (columns B, D, E, F) are being drawn with the wrong coloring.

NOTES:
The testcase (testcase 1) exercises 6 different conditions per row:
A) background: [named color]
B) ...with "will-change: transform"
C) ...and with a transparent "border-left" (this makes a difference, for some reason!)

D) background: linear-gradient([named color], [that same named color])
E) ...with "will-change: transform"
F) ...and with a transparent "border-left"

(Note: I suspect this bug is the underlying issue behind bug 1569411; I'm spinning this bug off as a new bug, though, because I'm not sure whether there are additional factors there, and because that bug took a bit of a journey before arriving at the color management pref as a possible factor.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 in Firefox Nightly (w/ pref-flip) vs. Chrome

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: with an actual transform instead of will-change:transform

Interestingly: if I change the testcase to trigger layerization using an actual transform (transform: rotate(1deg)) instead of will-change:transform, then swatch B changes to match A and C (i.e. to match the correct rendering, I think).

Here's a testcase with that change.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 in Firefox Nightly (w/ pref-flip) vs. Chrome

Comment 4

[Daniel Holbert [:dholbert]]

ni=aosmond to weigh in on whether this bug should block the pref-flip in bug 455077 (at least, that pref flip hitting release)

I suspect it may want to block, since it may mean hover/animation effects may trigger unexpected color changes, e.g. in bug 1569411...

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

For basic, I appear to have fixed (for my color profile) this for Basic compositor on Linux. However it is still the same with WebRender.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

Fixed with bug 1618345 I mean.

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

Ah this is because it manually copies the values into the structure. Ugh. I will fix this and add the test case to the reftests.

https://searchfox.org/mozilla-central/rev/070a000dd49aac4a26147e137efcd91a728d13b8/layout/painting/nsCSSRenderingGradients.cpp#1188

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1616444 - Ensure gradients are properly color managed with WebRender.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4e566b4fa61c
Ensure gradients are properly color managed with WebRender. r=jrmuizel

Comment 11

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/4e566b4fa61c

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:aosmond, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 13

[Andrew Osmond [:aosmond] (he/him)]

This can ride the trains.

Comment 14

[Daniel Holbert [:dholbert]]

Verified fixed in Nightly 76.0a1 (2020-03-12) (64-bit) on Ubuntu 19.10, using the testcases here and the codepen from dupe bug 1569411 comment 9, in a profile with gfx.color_management.mode = 1.