Ensure all colors passed into drawing APIs honour color management configuration
Categories
(Core :: Graphics: Color Management, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox76 | --- | fixed |
People
(Reporter: aosmond, Assigned: aosmond)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
|
(deleted),
text/x-phabricator-request
|
Details |
Today there are many paths to drawing pixels with particular colors. We don't enforce that these are color managed via ToDeviceColor, and as such, not all of them are. We need to ensure we are consistent. This is likely a long arduous task but we can't turn on color management everywhere unless we do that first, because otherwise one may see things side by side that should be the same color and are actually different.
|
Assignee | |
Comment 1•5 years ago
|
||
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•