Adds monitor ICC profile support for win and mac

ui/gfx/color_profile.cc

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "color_profile.h"
+
+#include "base/logging.h"
+
+namespace gfx {
+
+void ColorProfile::GetColorProfile(gfx::NativeViewId parent_window,
+                                   std::vector<char>* profile) {
+  // Called from the FILE thread on Windows and IO thread elsewhere.
+  // Force data to leak so exit time destructors are not called.
+  static std::map<gfx::NativeViewId, std::vector<char> >& data =
+      *new std::map<gfx::NativeViewId, std::vector<char> >();
+

[Noel Gordon, 2012/06/21 16:58:33]

You could add a DCHECK(!parent_window) here, because it is always 0 currently.

General design issues: let's just imagine you could get the actual HWND.  Chrome
creates a new HWND for each renderer and those HWND are unique.  But this data
map<> is keyed on HWND so it could grow quite large, no?

But maybe |parent_window| is the browser HWND? (It's not clear to me from
reading the code).  Smaller data map ok, but still not ideal.

Start chrome and tear off a tab, and use Visual Studio Spy++ to examine the
relationships b/w browser HWND and their renderer HWND.  Do that, and I think
you'll resolve the questions you're yet to tackle: which HWND should it be, does
it really matter, and why should WebCore care?

Anyho, those are just design issues to think about.  Currently |parent_window|
is always 0.  If we get to the point where it's not, then a map<HWND,
std::vector> > won't really cut it.

[tpayne, 2012/07/02 19:22:32]

Done.

+  profile->clear();
+  std::vector<char> stored_profile;
+  if (data.find(parent_window) == data.end()) {
+    ReadProfile(parent_window, &stored_profile);
+    data[parent_window] = stored_profile;
+  }
+
+  profile->assign(data[parent_window].begin(), data[parent_window].end());
+}
+
+}  // namespace gfx