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
Committed: https://crrev.com/1f846bac3526dde2ba5384157fbfff49acdc9f47
Cr-Commit-Position: refs/heads/master@{#428895}

[ccameron, 2016-10-31 23:07:50]

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

BUG=654488
==========

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

[ccameron, 2016-10-31 23:07:51]

ccameron@chromium.org changed reviewers:
+ hubbe@chromium.org

[ccameron, 2016-10-31 23:07:57]

The CQ bit was checked by ccameron@chromium.org to run a CQ dry run

[ccameron, 2016-10-31 23:08:23]

ccameron@chromium.org changed reviewers:
+ erikchen@chromium.org
- hubbe@chromium.org

[commit-bot: I haz the power, 2016-10-31 23:08:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[ccameron, 2016-10-31 23:08:59]

There is discussion and testing of this approach in
https://bugs.chromium.org/p/chromium/issues/detail?id=654488

The fix isn't great, but something more comprehensive would be dangerous and
complicated.

[erikchen, 2016-10-31 23:16:08]

lgtm

[ccameron, 2016-10-31 23:18:14]

The CQ bit was checked by ccameron@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-31 23:18:30]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-01 00:30:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-01 00:30:08]

Dry run: This issue passed the CQ dry run.

[ccameron, 2016-11-01 01:09:54]

The CQ bit was checked by ccameron@chromium.org

[commit-bot: I haz the power, 2016-11-01 01:10:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-01 01:15:33]

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

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

[commit-bot: I haz the power, 2016-11-01 01:15:34]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-01 01:18:24]

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

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

Committed: https://crrev.com/1f846bac3526dde2ba5384157fbfff49acdc9f47
Cr-Commit-Position: refs/heads/master@{#428895}
==========

[commit-bot: I haz the power, 2016-11-01 01:18:25]

Patchset 1 (id:??) landed as
https://crrev.com/1f846bac3526dde2ba5384157fbfff49acdc9f47
Cr-Commit-Position: refs/heads/master@{#428895}