Just in case it's not obvious, you'll need to handle (skip?) 4:4:4 and 4:2:2 sub-sampling and also apply the embedded color profile.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this worth looking into?

I remember doing a quick first pass investigation of this long ago. My understanding then was the code path wasn't in place to pass around YUV content in either the raster or render pipeline. Or maybe it was both.

IIRC, we were unable to create YUV textures on certain devices (old Android devices with buggy drivers?). And there wasn't a system in place for the higher level systems to request whether or not this device was able to create YUV textures. I also recall investigating using 3 planes of single-channel textures and a shader to combine them. That also wasn't a good fit for the existing system.

I would love for us to support YUV where we can. And I would love if the higher up systems could query what formats the hardware supported and passed those to the image decoders.

Maybe we are in a better position today to do this? What do the rest of you think?

SkImage supports yuv textures and so I think we could do this in GpuImageDecodeCache.

cblume: Do you have more information about where and why YUV textures weren't supported?

Also, maybe this is well enough scoped and off the critical path to be an intern project?

I do not have information about why it wasn't supported any more.
In fact, I think I was only told it and never saw the code.

If we support it then great!

I hope my previous message didn't sound down on the idea. I fully support the idea. I was just chiming in that there might or might not be a stopper.

And I agree, this might make a great intern project.

From a recent email thread discussing this:

bsalomon@ wrote:
> Skia has support for consuming YUV planes from CPU memory and converting to a
> RGBA texture on the GPU. It relies on the SkImageGenerator subclass
> implementing onGetYUV8Planes.

(This is implemented by SkiaPaintImageGenerator, which calls through to DecodingImageGenerator::GetYUV8Planes.)

> I don't know if this is currently used in the
> code path that Chrome goes through when making texture-backed SkImages.
> +Brian Osman

Skia has functionality for ingesting YUV planes, but it still produces an RGB texture from that (in our cache). There has been discussion of texturing directly from YUV planes, but my understanding is that it's a ways off, still.

I'll also caution about the color space transformation - for sufficiently complex profiles (which are rare), we won't be able to do this at all - we only support doing simple transforms on the GPU. Even then - for most encoded images, we've been moving to a world where we transform to the destination's color space before caching, to save GPU work during (repeated) rendering. So there would definitely be a tradeoff of RAM and bandwidth with additional fragment shader work to convert to the display's color profile.