Color color conversion happens at two steps in the display pipeline
Place 1: Raster time
Here we try to raster into whatever the "right space" is. This can be the output display space, or sRGB (for canvas), etc.
Place 2: Display time
Here we convert whatever inputs we have -- video, tiles, canvases, etc, into the display's color space. This is only done for GPU compositing.
For software compositing, color conversion at composite time is too slow to contemplate, so we don't do it. We raster everything into sRGB (see LayerTreeHostImpl::GetRasterColorSpace), and then display everything as sRGB.
Skia currently has 2 color conversion APIs:
API 1: Set a SkColorSpace on your output SkSurfaces, input SkImages, and input/output SkBitmaps, etc, and color conversion is done **on the fly** everywhere. This also opts you into linear blending, which is not compatible with the web.
API 2: Wrap all of your canvases in a SkColorSpaceXformCanvas, and tag your input SkImages only. This does not opt you into linear blending, but it does not do conversion on the fly -- it calls SkImage::makeColorSpace on all input images, making a color-converted copy of the images that weren't already in the destination space.
We currently use API 2 for rasterization, and we (at least try to) make all SkImages have the same color space as the destination, so that no color-conversion-copies are made. Making color-conversion-copies of SkImages is expensive, and whenever we don't succeed in pre-converting all images, performance bugs appear.
Using API 1 for compositing is not possible, because linear blending is not compatible with existing web content.
Using API 2 for compositing is not possible, because we will always have input images that are not in the output color space (e.g, canvas is sRGB, video is lots of things).
Ultimately we will want an API which allows for
- on-the-fly (in-shader) conversion
- without linear blending
This may be similar to the idea of a kNonLinearBlending_ColorSpaceFlag that was pursued in issue 697675 , but was abandoned in favor of the SkColorSpaceXformCanvas approach due to complexity of the implementation.
Another issue that may need to be addressed is that there are also color spaces (HDR video, for example, or YUV video) that do not have a SkColorSpace representation.
Comment 1 by vmi...@chromium.org
, Dec 15 2017