Attaching a more reasonable image.

Deleted: tot-fixed-preview.jpg 278 KB

	tot-fixed-preview.jpg 278 KB View Download

Hey Chris - for completeness, is the bottom-middle image one on a build of Chrome with your proposed reasonable fix of tagging all IOSurfaces as being in the output monitor color space?

Yes, exactly -- the bottom one is the proposed fix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1f846bac3526dde2ba5384157fbfff49acdc9f47

commit 1f846bac3526dde2ba5384157fbfff49acdc9f47
Author: ccameron <ccameron@chromium.org>
Date: Tue Nov 01 01:15:07 2016

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}

[modify] https://crrev.com/1f846bac3526dde2ba5384157fbfff49acdc9f47/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/1f846bac3526dde2ba5384157fbfff49acdc9f47/ui/display/mac/screen_mac.mm
[modify] https://crrev.com/1f846bac3526dde2ba5384157fbfff49acdc9f47/ui/gfx/mac/io_surface.cc

Requesting Merge to 55

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6596596075eb0b67b4bf908dc928f470b2d759af

commit 6596596075eb0b67b4bf908dc928f470b2d759af
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Nov 03 21:50:58 2016

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)

Review URL: https://codereview.chromium.org/2480583002 .

Cr-Commit-Position: refs/branch-heads/2883@{#446}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/6596596075eb0b67b4bf908dc928f470b2d759af/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/6596596075eb0b67b4bf908dc928f470b2d759af/ui/display/mac/screen_mac.mm
[modify] https://crrev.com/6596596075eb0b67b4bf908dc928f470b2d759af/ui/gfx/mac/io_surface.cc

Tested the issue on MacBook Retina using chrome version 55.0.2883.44 with the URL http://angled-edges.josephfus.co/ from the attached  bug 633805 .
Observed no rendering issues in the page.

Observing same behavior on reported version as well. please provide us any constant repro steps or sample URL to verify this issue from test team end.

Thanks,

This is fixed. Any image with an embedded color profile will cause the bug to appear, but it is necessary to set the system color profile to something noticeably different (e.g, ACES).

 Issue 692671  has been merged into this issue.