Plumb testRunner dynamic color profile test support into RenderWidget

Plumb testRunner dynamic color profile test support into RenderWidget

Follow on r269281 - plumb the JS API from testRunner.SetColorProfile
through to the render_widget where the color profile is stored.

Updating the webview() about any color profile change is done in the
render_view_impl: implementation of that is a TODO(noel).

BUG=369787
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=275720

[jochen (gone - plz use gerrit), 2014-06-05 06:58:45]

isn't the color profile a process wide setting (i.e. controlled via
blink::Platform)?

Why go via the webview then?

[Noel Gordon, 2014-06-05 07:08:36]

On 2014/06/05 06:58:45, jochen wrote:
> isn't the color profile a process wide setting (i.e. controlled via
> blink::Platform)?

The color profile is a Page-level setting.  Pages can be same process, but shown
on different monitors.

[Noel Gordon, 2014-06-05 07:25:48]

Ahem s/setting/concept/ (it's not a setting).

[Ken Russell (switch to Gerrit), 2014-06-06 21:35:32]

Is there another OWNER who can approve this?

[jochen (gone - plz use gerrit), 2014-06-06 22:46:36]

On 2014/06/06 21:35:32, Ken Russell wrote:
> Is there another OWNER who can approve this?

Sorry for the delay

Can you point me at where this will be passed to blink? I only see color
profiles on PlatformScreen and that's not per view?

[Noel Gordon, 2014-06-07 02:17:39]

> On 2014/06/06 21:35:32, Ken Russell wrote:
> > Is there another OWNER who can approve this?
> 
> Sorry for the delay

There's a picture on the bug to show the interaction with Page.

https://code.google.com/p/chromium/issues/detail?id=369787#c6

The layout tests are here:

https://codereview.chromium.org/266383003

Goal is to get this in a testable state, then iterate.

> Can you point me at where this will be passed to blink?

https://codereview.chromium.org/261633002

> I only see color profiles on PlatformScreen and that's not per view?

Sorry about that, and I agree that code is a bit confusing at first glance, let
me explain.  We currently support color profiled images for the primary
monitor/screen only.  The image decoders are the only part of the system that
use it at this time, and they read the primary monitor color profile with the
code you see in Platform screen.

Note that all other PlatformScreen code requires the Widget argument (basically
wraps their Page, making the API's per view).  The image decoders are
distinguished in that have no clue what Widget they are being used in, and they
are not allowed to call into Core to find out (since they are in
platform/graphics), and so can't currently provide the actual Widget to
PlatformScreen when they ask for the screen color profile.

So the current PlatformScreen API defaults to the primary monitor profile only. 
It's sufficient for the single monitor case and needs to be maintained while we
build out the code to make color profiles work for multiple monitors (per view)
behind a flag.  Bit of a pita, but I don't intend to break what we have now.

Longer term, per view color correction support also has to be moved out of the
image decoders to a better place (maybe GraphicsContext) to tackle the general
problem at hand: color correction of web content [1].

[1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0093.html

[jochen (gone - plz use gerrit), 2014-06-07 05:42:05]

Thanks for the clarification. lgtm

[Noel Gordon, 2014-06-08 01:03:18]

The CQ bit was checked by noel@chromium.org

[commit-bot: I haz the power, 2014-06-08 01:03:55]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/noel@chromium.org/316913002/1

[commit-bot: I haz the power, 2014-06-08 02:16:30]

Change committed as 275720