1696688 - Set IOSurface color space to sRGB

Status: RESOLVED FIXED

(Core :: Graphics, enhancement)

Description

[Jeff Muizelaar [:jrmuizel]]

This should get us working color management basically for free.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

From: https://bugs.chromium.org/p/chromium/issues/detail?id=417150#c34
"To summarize the above rambling:

If you tag an IOSurface with a Colorspace then you get the following behavior
changes:

• If you use the IOSurface as the contents of a CALayer, then the on-screen
  result will be color-corrected from the IOSurface's ColorSpace to the
  display's ColorSpace.
• If you use the IOSurface in OpenGL, its behavior is unaffected (so, we don't
  get color conversion in OpenGL for free).

If you tag an IOSurface with a ColorSpace then you get the following power
changes:

• If you tag an IOSurface with the ColorSpace of the monitor that it will
  appear on then there is no additional GPU power usage. It is equivalent to
  not having specified a ColorSpace
  • There is a slight increase in CPU power usage because of some
    bookkeeping looking up the ColorSpace (roughly one call to
    CGColorSpaceCreateWithICCProfile per newly-rastered quad)
• If you tag an IOSurface with any other ColorSpace (e.g, RGB or SRGB), then
  there is a nontrivial-but-not-excessive cost in terms of GPU power usage
  that you incur every time you draw a frame."

Comment 2

[Jeff Muizelaar [:jrmuizel]]

So here's an interesting tidbit about what Chrome does:
https://source.chromium.org/chromium/chromium/src/+/master:ui/gfx/mac/display_icc_profiles.cc;l=73;drc=3930cf3f0e2404a517b4580b21e598a3fc648ff0

"If the ICC profile isn't accurately parametrically approximated, then don't store its data (we will assign the best parametric fit to IOSurfaces, and rely on the system compositor to do conversion to the display profile)."

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Here's where Chrome decides on an output space:
https://source.chromium.org/chromium/chromium/src/+/master:cc/trees/layer_tree_host_impl.cc;l=1786;drc=624b5fe84610fa05852203a2bcb0c0c995dd99dd

It uses color spaces decided here:
https://source.chromium.org/chromium/chromium/src/+/master:ui/display/mac/screen_mac.mm;l=58;drc=d29aea5fe2e3cafa6a84fda198d2e4c4ac5b1832

It detects HDR with:

  // Examine the presence of HDR.
  bool enable_hdr = false;
  if (@available(macOS 10.15, *)) {
    if ([screen maximumPotentialExtendedDynamicRangeColorComponentValue] >
        1.0) {
      enable_hdr = true;
    }
  }

And determines the rasterization colorspace here:
https://source.chromium.org/chromium/chromium/src/+/master:cc/trees/layer_tree_host_impl.cc;l=1786;drc=624b5fe84610fa05852203a2bcb0c0c995dd99dd

For example, if I set my laptop to an Adobe RGB profile, hdr is still detected and I end up with my IOSurfaces tagged with P3 because of this check:

  if (result.IsHDR() && content_color_usage != gfx::ContentColorUsage::kHDR)
    return gfx::ColorSpace::CreateDisplayP3D65();

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I'm pretty sure I was previously able to get Chrome to tag with a colorspace other than P3 but I can't seem to make that happen anymore.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

QuartzCore seems to use CGColorSpaceUsesExtendedRange when deciding about whether to use 16bpc or 8bpc

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bug 1696688. Set IOSurface color space to sRGB.

This lets the WindowServer do all of the color correction for us
including WebGL and 2D canvas.

There's some concern that this will increase GPU usage as
reported in https://bugs.chromium.org/p/chromium/issues/detail?id=417150#c34.
However, the alernative of doing everything in device space isn't very
attractive because we'd have to color manage canvas and webgl ourselves.

Further, Chrome doesn't seem to be using the device space and it seems
like there's typically already a mix of color spaces in use so hopefully
the GPU increase is not high.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/986fc0850be4
Set IOSurface color space to sRGB. r=mstange

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/986fc0850be4

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Colors in Firefox on macOS will no longer be saturated on wide gamut displays, untagged images are properly treated as sRGB, and colors in images tagged as sRGB will now match css colors.
[Affects Firefox for Android]: Nope
[Suggested wording]: I'm not sure.
[Links (documentation, blog post, etc)]: None yet.

Comment 10

[Pascal Chevrel:pascalc]

Added to nightly release notes with the text explaining the change:
Colors in Firefox on macOS will no longer be saturated on wide gamut displays, untagged images are properly treated as sRGB, and colors in images tagged as sRGB will now match css colors.

Comment 11

[Pascal Chevrel:pascalc]

This is in our 89 beta notes and should be in our final notes managed by our comms team.