Mac: Workaround IOSurface color behavior change in 10.12

Mac: Workaround IOSurface color behavior change in 10.12

IOSurface color handling for remote layers changed in Sierra.

Prior to sierra, these were assumed to be in the display device color
space of whichever monitor they appeared on (that is, no color
conversion was applied).

We currently decode images into what we guess to be the device color
space (initialized once at renderer process create time), and assume
that the image will appear on that monitor and that the compositor will
apply no color correction.

This assumption is now invalid, and we will get sRGB->(device color
space) conversion, unless we explicitly tag the IOSurface.

A comprehensive fix for this is complicated (working on it).

In the mean time, force image decode to be done in
base::mac::GetSystemColorSpace, and tag all IOSurfaces as being in
base::mac::GetSystemColorSpace. Note that base::mac::GetSystemColorSpace
is static for the duration of the process it is called from.

In this fix we call base::mac::GetSystemColorSpace in the browser and
GPU processes and hope that they are in sync (the only time they won't
be is if the GPU process crashes and the monitor configuration changed
in the mean time).

Also of note is that I tried changing GetSystemColorSpace to get the
"deepest" screen's color space, but that did not correspond to the space
with the widest gamut, so I left it as-is.

BUG=654488
Review-Url: https://codereview.chromium.org/2462283002
Cr-Commit-Position: refs/heads/master@{#428895}
(cherry picked from commit 1f846bac3526dde2ba5384157fbfff49acdc9f47)

Committed: https://chromium.googlesource.com/chromium/src/+/6596596075eb0b67b4bf908dc928f470b2d759af

[ccameron, 2016-11-03 21:55:17]

Description was changed from

==========
Mac: Workaround IOSurface color behavior change in 10.12

IOSurface color handling for remote layers changed in Sierra.

Prior to sierra, these were assumed to be in the display device color
space of whichever monitor they appeared on (that is, no color
conversion was applied).

We currently decode images into what we guess to be the device color
space (initialized once at renderer process create time), and assume
that the image will appear on that monitor and that the compositor will
apply no color correction.

This assumption is now invalid, and we will get sRGB->(device color
space) conversion, unless we explicitly tag the IOSurface.

A comprehensive fix for this is complicated (working on it).

In the mean time, force image decode to be done in
base::mac::GetSystemColorSpace, and tag all IOSurfaces as being in
base::mac::GetSystemColorSpace. Note that base::mac::GetSystemColorSpace
is static for the duration of the process it is called from.

In this fix we call base::mac::GetSystemColorSpace in the browser and
GPU processes and hope that they are in sync (the only time they won't
be is if the GPU process crashes and the monitor configuration changed
in the mean time).

Also of note is that I tried changing GetSystemColorSpace to get the
"deepest" screen's color space, but that did not correspond to the space
with the widest gamut, so I left it as-is.

BUG=654488

Review-Url: https://codereview.chromium.org/2462283002
Cr-Commit-Position: refs/heads/master@{#428895}
(cherry picked from commit 1f846bac3526dde2ba5384157fbfff49acdc9f47)
==========

to

==========
Mac: Workaround IOSurface color behavior change in 10.12

IOSurface color handling for remote layers changed in Sierra.

Prior to sierra, these were assumed to be in the display device color
space of whichever monitor they appeared on (that is, no color
conversion was applied).

We currently decode images into what we guess to be the device color
space (initialized once at renderer process create time), and assume
that the image will appear on that monitor and that the compositor will
apply no color correction.

This assumption is now invalid, and we will get sRGB->(device color
space) conversion, unless we explicitly tag the IOSurface.

A comprehensive fix for this is complicated (working on it).

In the mean time, force image decode to be done in
base::mac::GetSystemColorSpace, and tag all IOSurfaces as being in
base::mac::GetSystemColorSpace. Note that base::mac::GetSystemColorSpace
is static for the duration of the process it is called from.

In this fix we call base::mac::GetSystemColorSpace in the browser and
GPU processes and hope that they are in sync (the only time they won't
be is if the GPU process crashes and the monitor configuration changed
in the mean time).

Also of note is that I tried changing GetSystemColorSpace to get the
"deepest" screen's color space, but that did not correspond to the space
with the widest gamut, so I left it as-is.

BUG=654488

Review-Url: https://codereview.chromium.org/2462283002
Cr-Commit-Position: refs/heads/master@{#428895}
(cherry picked from commit 1f846bac3526dde2ba5384157fbfff49acdc9f47)

Committed:
https://chromium.googlesource.com/chromium/src/+/6596596075eb0b67b4bf908dc928...
==========

[ccameron, 2016-11-03 21:55:18]

Committed patchset #1 (id:1) manually as
6596596075eb0b67b4bf908dc928f470b2d759af.