ccameron, could you please triage?

We'll need to keep an eye on this as we ship color correct rendering, but I don't think this will be fixed. In particular, we have two options

1. Make creating the renderer wait for UpdateCachedProfilesOnBackgroundThread to complete.
2. Create the first renderer with sRGB and update its color profile when UpdateCachedProfilesOnBackgroundThread completes.

I suspect that there will be resistance to [1] and no resistance to [2] (especially if we add a UMA histogram to know how often we actually create the renderer with no color space and we find it to be "infrequent"). That said, if this impacts things that we expose to the web (e.g, "are you on a HDR or WCG display"), that may shift the appetite towards [1].

I'll keep this open for now and put it as blocking on  issue 667431 .

ICC profiles and HDR capabilities can change as you plug in monitors anyways, so (2) sounds like the right approach to me.

I spent a while today and yesterday trying to see if there is any way to get access to the ICC profile, or the color space parameters, without reading from the filesystem.

It is possible to not directly read from a file, by calling
  WcsGetDefaultColorProfile
which will give you a file name (hmm...), and then call
  OpenColorProfile
with arguments PROFILE_FILENAME and FILE_SHARE_READ. Which basically means "you're not reading from disk, but someone else is".

I'm finding myself in a slight analysis-paralysis about this. This will be much cleaner when it can be merged in with the display::Display code, but that's a sort-of-large refactor that I don't really have the appetite for right now.

This was fixed in https://codereview.chromium.org/2959423003 and  https://chromium-review.googlesource.com/564392

The first renderer and window may get a guess at the color space (sRGB), but they will get an update if the color space isn't sRGB (and only if it isn't).