Teach gfx::Screen about color profiles

ui/gfx/screen.h

Index: ui/gfx/screen.h
diff --git a/ui/gfx/screen.h b/ui/gfx/screen.h
index 1d36d1b51cbefb9bff481219a7bddb6596b6875c..15e66d116012ec63d22fc0dfc224223ec3005663 100644
--- a/ui/gfx/screen.h
+++ b/ui/gfx/screen.h
@@ -73,6 +73,10 @@ class GFX_EXPORT Screen {
   // Returns the display nearest the specified window.
   virtual gfx::Display GetDisplayNearestWindow(NativeView view) const = 0;
 
+  // Returns the color profile of the display nearest the window.

[Ken Russell (switch to Gerrit), 2014/04/30 17:43:17]

Could you add a little more documentation here? What exactly does the color
profile contain upon return? An ICC color profile? Something different?

[Noel Gordon, 2014/04/30 17:51:29]

Yeah good point. Would this work for you? 

// Returns the ICC color profile data of the display nearest the window.

[Ken Russell (switch to Gerrit), 2014/04/30 17:52:02]

Sounds good.

[Noel Gordon, 2014/05/01 05:24:55]

Done.

+  virtual bool GetDisplayColorProfile(
+      NativeView view, std::vector<char>* color_profile) const = 0;

[oshima, 2014/04/30 18:18:53]

Can you define a class (or struct) for color profile (in ui/display),
and document the format there? Do you think it's overkill?

Also, is it difficult to use display (or display_id) as a parameter instead of
native view?

[Noel Gordon, 2014/05/01 05:52:21]

Yes I think that'd be overkill.  At this level of the system, we just return the
ICC data. The higher level systems that use this data, know how to validate and
process it.  The structure of ICC data is covered by well-know and widely-used
international standard published by the ICC www.color.org, and is of
interest only to color management system software. gfx:Screen is not a color
management system, nor does it need to be.

[Noel Gordon, 2014/05/01 07:33:24]

Good question.

Yeap, difficult. gfx::Display is no good because of the propensity of Screen to
use the default screen information when there is no window/view, when asking the
screen for the display nearest window, as but one example. That behavior leads
to bugs like http://crbug.com/357443 https://crbug.com/342672 and I need much
better control than that.

I believe I discussed the with you 6 weeks ago on http://crbug.com/357443 when I
asked about the implementation of display_id() on mac-osx.  I'd be fine with an
ephemeral display_id() btw, but no answers from the mac folks on that bug.  Six
weeks might be considered sufficient time to provide an answer.  I'm a patient
man, but only so much, and I decided to work-around the entire issue of
display_id() by redesigning to _not rely on it at all_. 

I no longer care about display_id() on mac or elsewhere. I can make use of it
internally on the windows port, but not as part of the api.

Also, using NativeView in the api works with the call sites in RenderViewHost
and RenderWidgetHost.  They call GetDisplayNearestWindow(NativeView) (and tickle
bugs 357443 and 342672 in the process) when they read Blink::WebScreenInfo that
needs to be sent to Blink renderers.  I get the screen color profile via
GetDisplayColorProfile(NativeView) nearby, so using the NativeView in the API is
a much better fit all round.

You will see in the prelude (implementations of this api for mac and win) that
most sane operating systems provide an API to get the the color profile of the
associated screen _given the NativeView (window)_.  The chrome-os and linux crew
could learn from that.  I'm not going to implement this api for them though --
they seem to be undecided in this area based on the bugs I filed on them.  I'll
leave a TODO(port) hook, but those OSes need to interwork with us here, not the
other way around.

Hope that answers your question.

+
   // Returns the display nearest the specified point.
   virtual gfx::Display GetDisplayNearestPoint(
       const gfx::Point& point) const = 0;