viz: Respect color space for SkiaRenderer copies
When fulfulling RGBA_BITMAP copy requests, SkiaRenderer does not pass a color space to asyncRescaleAndReadPixels which according to the Skia documentation [1], means that Skia will default to a sRGB conversion. However, when the color space isn't sRGB (e.g. HDR videos), the non-sRGB color space is still passed via ReadPixelsContext to initialize the SkBitmap [2]. Thus, even though the image was converted to sRGB in the read, the SkBitmap reports that it is in a non-sRGB color space. This CL fixes this issue by explicitly providing a SkColorSpace to asyncRescaleAndReadPixels via a conversion from gfx::ColorSpace. Additionally, if the gfx::ColorSpace cannot be converted to an SkColorSpace (e.g. PIECEWISE_HDR), fallback to sRGB. This fallback fixes a null pointer dereference in Chrome OS [3], and for more context, see the CL for a similar fix in GLRenderer [4]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/skia/include/core/SkImageInfo.h;l=296;drc=a450ab794839b63f9c2ba982f738945f90e9fee2 [2] https://source.chromium.org/chromium/chromium/src/+/master:components/viz/service/display_embedder/skia_output_surface_impl_on_gpu.cc;l=214;drc=a450ab794839b63f9c2ba982f738945f90e9fee2 [3] https://source.chromium.org/chromium/chromium/src/+/master:components/viz/service/frame_sinks/video_capture/frame_sink_video_capturer_impl.cc;l=753;drc=e0789c0a2326279a3bac70012ca3edd3e46b5aa1 [4] https://chromium-review.googlesource.com/c/chromium/src/+/2464100 Bug: 1138518 Change-Id: I4ccd5b6e9af75caff917fa851281eae7ee8f10cc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2472437Reviewed-by:Jonathan Backer <backer@chromium.org> Commit-Queue: Brian Ho <hob@chromium.org> Cr-Commit-Position: refs/heads/master@{#817140}
Showing
Please register or sign in to comment