cc: Plumb the monitor color profile to renderer for rasterization

cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Committed: https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4
Cr-Original-Commit-Position: refs/heads/master@{#418422}
Cr-Commit-Position: refs/heads/master@{#418591}

[ccameron, 2016-09-08 21:38:19]

Description was changed from

==========
Plumb

BUG=
==========

to

==========
Plumb

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[ccameron, 2016-09-08 21:47:08]

Description was changed from

==========
Plumb

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
cc::LayerTreeHost, from where it is pushed to the cc::LayerTreeImpl.

In the next step, we will (under a flag) specify the color space
for rasterization.

Add unit tests to ensure that properties are propagated appropriately.

BUG=44872
==========

[ccameron, 2016-09-08 21:47:08]

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

[ccameron, 2016-09-08 21:48:30]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
cc::LayerTreeHost, from where it is pushed to the cc::LayerTreeImpl.

In the next step, we will (under a flag) specify the color space
for rasterization.

Add unit tests to ensure that properties are propagated appropriately.

BUG=44872
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
cc::LayerTreeHost, from where it is pushed to the cc::LayerTreeImpl.

In the next step, we will (under a flag) specify the color space
for rasterization.

Add unit tests to ensure that properties are propagated appropriately.

BUG=44872
==========

[ccameron, 2016-09-08 22:04:29]

ccameron@chromium.org changed reviewers:
+ clamy@chromium.org, dcheng@chromium.org

[ccameron, 2016-09-08 22:05:03]

ptal:

enne: cc (and ui)
clamy: content OWNER
dcheng: view_messages OWNER

https://codereview.chromium.org/2325773003/diff/20001/content/common/view_mes...
File content/common/view_messages.h (right):

https://codereview.chromium.org/2325773003/diff/20001/content/common/view_mes...
content/common/view_messages.h:173: IPC_STRUCT_TRAITS_MEMBER(icc_profile)
We send this same ICC profile here
https://cs.chromium.org/chromium/src/content/common/view_messages.h?rcl=0&l=500
That ICC profile is ignored in the new color correction path
(--enable-color-correct-rendering), and will be deleted when the old path goes
away.

https://codereview.chromium.org/2325773003/diff/20001/ui/display/BUILD.gn
File ui/display/BUILD.gn (right):

https://codereview.chromium.org/2325773003/diff/20001/ui/display/BUILD.gn#new...
ui/display/BUILD.gn:82: ]
This was required because of the gn error:

  ccameron-macbookpro:src ccameron$ gn gen out/gn --check
  ERROR at //ui/display/display.h:13:11: Can't include this header from here.
  #include "ui/gfx/icc_profile.h"
            ^-------------------
  The target:
    //services/ui/public/interfaces/display:display_cpp_sources
  is including a file from the target:
    //ui/gfx:gfx

  It's usually best to depend directly on the destination target.
  In some cases, the destination target is considered a subcomponent
  of an intermediate target. In this case, the intermediate target
  should depend publicly on the destination to forward the ability
  to include headers.

  Dependency chain (there may also be others):
    //services/ui/public/interfaces/display:display_cpp_sources -->
    //ui/display:display --[private]-->
    //ui/gfx:gfx

https://codereview.chromium.org/2325773003/diff/20001/ui/display/display.h
File ui/display/display.h (right):

https://codereview.chromium.org/2325773003/diff/20001/ui/display/display.h#ne...
ui/display/display.h:175: int color_depth() const { return color_depth_; }
These variables are:
- populated to something besides RGBA_8888 only on Android
- don't come from the ICC profile (and may be at odds with the ICC profile) on
Android
- correspond to WebScreenInfo data.
- it eventually becomes query-able in JS

So, we can't get rid of color_depth and depth_per_component :(

[enne (OOO), 2016-09-09 00:31:05]

cc lgtm
I'm not a ui owner.

[clamy, 2016-09-09 15:23:25]

Thanks! The code in the cross-platform part of content/ looks good, but I'm not
familiar with mac specifics. Could you get someone more familiar to review it
before I stamp it?

[ccameron, 2016-09-09 16:12:55]

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

[ccameron, 2016-09-09 16:13:21]

Sure -- adding ellyjones for the .mm changes in content/

[enne (OOO), 2016-09-09 17:44:47]

https://codereview.chromium.org/2325773003/diff/20001/cc/trees/layer_tree_imp...
File cc/trees/layer_tree_impl.cc (right):

https://codereview.chromium.org/2325773003/diff/20001/cc/trees/layer_tree_imp...
cc/trees/layer_tree_impl.cc:849: // set_needs_update_draw_properties();
?

[ccameron, 2016-09-09 17:48:18]

https://codereview.chromium.org/2325773003/diff/20001/cc/trees/layer_tree_imp...
File cc/trees/layer_tree_impl.cc (right):

https://codereview.chromium.org/2325773003/diff/20001/cc/trees/layer_tree_imp...
cc/trees/layer_tree_impl.cc:849: // set_needs_update_draw_properties();
On 2016/09/09 17:44:47, enne wrote:
> ?

Oooooops, I was verifying that the tests would actually fail when those lines
were dropped!

[dcheng, 2016-09-09 19:32:19]

ipc lgtm, let me know if I misunderstood something here though.

https://codereview.chromium.org/2325773003/diff/20001/content/common/view_mes...
File content/common/view_messages.h (right):

https://codereview.chromium.org/2325773003/diff/20001/content/common/view_mes...
content/common/view_messages.h:173: IPC_STRUCT_TRAITS_MEMBER(icc_profile)
On 2016/09/08 22:05:03, ccameron wrote:
> We send this same ICC profile here
>
https://cs.chromium.org/chromium/src/content/common/view_messages.h?rcl=0&l=500
> That ICC profile is ignored in the new color correction path
> (--enable-color-correct-rendering), and will be deleted when the old path goes
> away.

My understanding is we're sending this from browser -> renderer, which is OK.

[ccameron, 2016-09-10 00:59:22]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
cc::LayerTreeHost, from where it is pushed to the cc::LayerTreeImpl.

In the next step, we will (under a flag) specify the color space
for rasterization.

Add unit tests to ensure that properties are propagated appropriately.

BUG=44872
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
cc::LayerTreeHost, from where it is pushed to the cc::LayerTreeImpl.

In the next step, we will (under a flag) specify the color space
for rasterization.

Add unit tests to ensure that properties are propagated appropriately.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[ccameron, 2016-09-10 01:10:55]

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

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

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-09-10 01:25:45]

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

[commit-bot: I haz the power, 2016-09-10 01:25:46]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[ccameron, 2016-09-11 20:10:35]

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

[commit-bot: I haz the power, 2016-09-11 20:10:37]

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-09-11 21:36:36]

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

[commit-bot: I haz the power, 2016-09-11 21:36:37]

Dry run: This issue passed the CQ dry run.

[ccameron, 2016-09-12 20:13:19]

https://codereview.chromium.org/2325773003/diff/80001/ui/display/mac/screen_m...
File ui/display/mac/screen_mac.mm (right):

https://codereview.chromium.org/2325773003/diff/80001/ui/display/mac/screen_m...
ui/display/mac/screen_mac.mm:83:
display.set_is_monochrome(CGDisplayUsesForceToGray());
note that this a change from the previous behavior -- this matches WebKit's
macOS implementation (see
https://github.com/WebKit/webkit/blob/c84b4f3f42031a83386a985708ce72dc171c70d...).

[no sievers, 2016-09-12 22:05:17]

content lgtm

[ccameron, 2016-09-12 22:05:36]

The CQ bit was checked by ccameron@chromium.org

[ccameron, 2016-09-12 22:05:37]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org,
enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2325773003/#ps80001
(title: "Rebase")

[commit-bot: I haz the power, 2016-09-12 22:06:20]

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

[ccameron, 2016-09-12 22:23:20]

The CQ bit was unchecked by ccameron@chromium.org

[ccameron, 2016-09-13 22:43:15]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
cc::LayerTreeHost, from where it is pushed to the cc::LayerTreeImpl.

In the next step, we will (under a flag) specify the color space
for rasterization.

Add unit tests to ensure that properties are propagated appropriately.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[ccameron, 2016-09-13 22:43:36]

The CQ bit was checked by ccameron@chromium.org

[ccameron, 2016-09-13 22:43:37]

The patchset sent to the CQ was uploaded after l-g-t-m from
sievers@chromium.org, dcheng@chromium.org, enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2325773003/#ps100001
(title: "Remove cc part")

[commit-bot: I haz the power, 2016-09-13 22:44:16]

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

[ccameron, 2016-09-13 22:44:29]

> CQ is trying da patch.

FYI, I dropped the cc:: part of the patch, since it'll fit better with this (in
progress) patch https://codereview.chromium.org/2336853002/

[commit-bot: I haz the power, 2016-09-14 00:04:35]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[commit-bot: I haz the power, 2016-09-14 00:04:36]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-09-14 00:06:34]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Cr-Commit-Position: refs/heads/master@{#418422}
==========

[commit-bot: I haz the power, 2016-09-14 00:06:36]

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

[Yuta Kitamura, 2016-09-14 05:03:59]

A revert of this CL (patchset #6 id:100001) has been created in
https://codereview.chromium.org/2336113003/ by yutak@chromium.org.

The reason for reverting is: Suspected cause of the following MSAN failure.

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20MSAN/b...

19:03:27.700 29717   ==4==WARNING: MemorySanitizer: use-of-uninitialized-value
19:03:27.700 29717       #0 0x7853dbe in computeTypeMask
third_party/skia/src/core/SkMatrix44.cpp:59:23
19:03:27.700 29717       #1 0x7858825 in getType
third_party/skia/include/core/SkMatrix44.h:208:31
19:03:27.700 29717       #2 0x7858825 in setConcat
third_party/skia/src/core/SkMatrix44.cpp:378:0
19:03:27.700 29717       #3 0x76f8840 in operator*= ui/gfx/transform.h:253:5
19:03:27.700 29717       #4 0x76f8840 in ColorSpaceToColorSpaceTransform
ui/gfx/color_transform.cc:563:0
19:03:27.700 29717       #5 0x76f78de in NewColorTransform
ui/gfx/color_transform.cc:703:15
19:03:27.700 29717       #6 0x767f315 in GetColorSpace
ui/gfx/icc_profile.cc:142:45
19:03:27.700 29717       #7 0xb2263ae in initializeLayerTreeView
content/renderer/render_widget.cc:1141:61
19:03:27.700 29717       #8 0xb1e68fd in initializeLayerTreeView
content/renderer/render_view_impl.cc:1956:17
19:03:27.700 29717       #9 0xc1c6b06 in initializeLayerTreeView
third_party/WebKit/Source/web/WebViewImpl.cpp:4341:19
19:03:27.700 29717       #10 0xc1c57bf in WebViewImpl
third_party/WebKit/Source/web/WebViewImpl.cpp:471:5
19:03:27.700 29717       #11 0xc1c29ff in create
third_party/WebKit/Source/web/WebViewImpl.cpp:342:25
19:03:27.700 29717       #12 0xc1c29ff in create
third_party/WebKit/Source/web/WebViewImpl.cpp:336:0
19:03:27.700 29717       #13 0xb19b457 in Initialize
content/renderer/render_view_impl.cc:717:7
<snip>.

[ccameron, 2016-09-14 07:31:44]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Cr-Commit-Position: refs/heads/master@{#418422}
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Cr-Commit-Position: refs/heads/master@{#418422}
==========

[ccameron, 2016-09-14 07:49:26]

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

[commit-bot: I haz the power, 2016-09-14 07:49:40]

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-09-14 09:11:15]

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

[commit-bot: I haz the power, 2016-09-14 09:11:16]

Dry run: This issue passed the CQ dry run.

[ccameron, 2016-09-14 16:48:12]

The CQ bit was checked by ccameron@chromium.org

[ccameron, 2016-09-14 16:48:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
sievers@chromium.org, dcheng@chromium.org, enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2325773003/#ps120001
(title: "Unrevert")

[commit-bot: I haz the power, 2016-09-14 16:48:38]

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-09-14 16:54:59]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Cr-Commit-Position: refs/heads/master@{#418422}
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Cr-Commit-Position: refs/heads/master@{#418422}
==========

[commit-bot: I haz the power, 2016-09-14 16:55:03]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-09-14 16:58:39]

Description was changed from

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Cr-Commit-Position: refs/heads/master@{#418422}
==========

to

==========
cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Committed: https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4
Cr-Original-Commit-Position: refs/heads/master@{#418422}
Cr-Commit-Position: refs/heads/master@{#418591}
==========

[commit-bot: I haz the power, 2016-09-14 16:58:40]

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