[WIP] cc: Use sRGB for rastering non-wide-color-gamut content

[WIP] cc: Use sRGB for rastering non-wide-color-gamut content

If all of the content of a layer is sRGB, then rasterize that layer as
sRGB and perform color conversion at compositing time.

BUG=719735
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

[ccameron, 2017-05-08 23:09:39]

Description was changed from

==========
[WIP] cc: Use sRGB for rastering non-wide-color-gamut content

If all of the content of a layer is sRGB, then rasterize that layer as
sRGB and perform color conversion at compositing time.

BUG=719735
==========

to

==========
[WIP] cc: Use sRGB for rastering non-wide-color-gamut content

If all of the content of a layer is sRGB, then rasterize that layer as
sRGB and perform color conversion at compositing time.

BUG=719735
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[ccameron, 2017-05-08 23:11:23]

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

[ccameron, 2017-05-08 23:11:24]

Not, like, for actual review, but, does this seem like a not-objectionable
approach?

I said "layer", but it actually works out to DisplayItemList, which happens to
be equivalent.

[vmpstr, 2017-05-09 22:58:27]

Yeah I think this patch is pretty good. We need to possibly figure out the
interaction with checker imaging as well, if we care, since sometimes we'll be
skipping images while drawing and sometimes not. I guess that can be an
optimization as a follow-up.

https://codereview.chromium.org/2866173002/diff/1/cc/paint/discardable_image_...
File cc/paint/discardable_image_map.cc (right):

https://codereview.chromium.org/2866173002/diff/1/cc/paint/discardable_image_...
cc/paint/discardable_image_map.cc:33: for (const auto& image_rect_pair :
all_images_) {
You can just pass &has_non_srgb_images_ to DiscardableImageStore ctor (like we
do with all_images_) and set it whenever we find an image. That saves an extra
pass through the images.

https://codereview.chromium.org/2866173002/diff/1/cc/paint/display_item_list.cc
File cc/paint/display_item_list.cc (right):

https://codereview.chromium.org/2866173002/diff/1/cc/paint/display_item_list....
cc/paint/display_item_list.cc:340: return image_map_.has_non_srgb_images();
One thing to note (and I think we're pretty far down this patch), but the whole
discardable image caching in the compositor only cares about lazy images. Things
like bitmaps and I think ico files just get passed through. I'm assuming those
don't specify an image space or we don't care?

https://codereview.chromium.org/2866173002/diff/1/cc/tiles/tile_manager.cc
File cc/tiles/tile_manager.cc (right):

https://codereview.chromium.org/2866173002/diff/1/cc/tiles/tile_manager.cc#ne...
cc/tiles/tile_manager.cc:1507: : gfx::ColorSpace::CreateSRGB();
Is this a cheap call? Assuming that everything is SRGB, this would be created
multiple times? Should we just have a static member or something?