Closed Bug 1616444 Opened 2 years ago Closed 2 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox75 --- wontfix
firefox76 --- verified

People

(Reporter: dholbert, Assigned: aosmond)

References

(Blocks 2 open bugs)

Details

Attachments

(5 files)

Attached file 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.)

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.

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

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...

Flags: needinfo?(aosmond)
Duplicate of this bug: 1569411
Priority: -- → P3

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.

Blocks: 1602453

Fixed with bug 1618345 I mean.

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

Assignee: nobody → aosmond
Status: NEW → ASSIGNED
Flags: needinfo?(aosmond)
Pushed by aosmond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4e566b4fa61c
Ensure gradients are properly color managed with WebRender. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

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.

Flags: needinfo?(aosmond)

This can ride the trains.

Flags: needinfo?(aosmond)

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.