Brian Osman has been working on adding MIP map generation code to Skia's GL backend to work around sRGB-related driver bugs.

Repro:
1. Navigate to chrome://flags
2. Enable experimental canvas features
3. Restart Chrome (big blue button)
4. navigate to: http://jsfiddle.net/zbs9cpm2/

Observed Result: 
In the top left corner, there are two thumbnails, the bottom one is black

Expected result:
The two thumbnails should look the same (% filtering quality)

Only Repros on ChromeOS.
Works fine when accelerated-2d-canvas is disabled

brianosman@: please update this issue once your mip map generation code is ready. 

If skia will be switching between driver/skia implementations of mipmap generation, then there should probably be a bit in glCaps that we can flip to tell Ganesh to never use the driver's implementation.

You can assign this issue back to me if anything needs be done on the blink/chromium side.

The code for the manual mip-map generation landed, and several more fixes went in, the most recent being: https://skia.googlesource.com/skia/+/21c5ec62aab4be1fa1bfa06167ce8fd4c9decb35

There is a caps bit (GrGLCaps::fDoManualMipmapping) that determines whether we use the driver (glGenerateMipmap) or the draw-call based code. Right now, we choose to use the new code path unless GPU or driver bugs prevent us from doing so. At the moment, the main classes of devices that still use the driver are:

- Adreno3xx : Inability to render to very small FBs prevent us from generating the full mip-chain.
- Adreno4xx : A driver bug with FB sRGB write-control causes us to (conservatively) opt-out for sRGB textures, but not others.
- Anything that's only running ES2, because we need the ability to set GL_TEXTURE_BASE_LEVEL during the downsample chain.

I'm also looking at performance results, to see if we should opt-out on GPUs (especially tilers) where the repeated render-to-texture/resolve cycle may be less efficient than whatever the driver was previously doing.

It sounds like the ChromeOS devices are using Intel chipsets? In that case, it's likely that they will pick up the new code-path be default, and should "just work". Fingers crossed.

Excellent! I'll check it out and let you know if there are any issues.

As a follow-up to this: Due to performance regression, we made this opt-in, rather than opt-out. That caps bit is now enabled when:

- Vendor == "Intel" or "ATI"
- Driver == "NVIDIA" && MacOS

That covers the machines in our testing that were failing to produce correct sRGB mip-maps with the driver. bsalomon@ informs me that ChromeOS doesn't report the actual GL vendor, so this may go back to not working for you, but we could add a flag to GrContextOptions that lets you override the behavior, if you'd like?

+Victor as this came up in the gpu raster meeting the other day. For context GrContextOptions is a means by which we can add client overrides for caps that we would otherwise infer from GL strings (among other uses). It is passed to the factory function that create GrContext.

@brianosman So I tried flipping the fDoManualMipmapping on my local chromeOS build and I get transparent black mipmaps (before I had opaque black). So it does something, but it still does not work.  Any ideas?

This issue is obsolete A workaround was implemented in the chromium gpu stack.