It looks like putting WebGL contexts into their own "real" OpenGL share group on the service side, by modifying GpuCommandBufferStub::Initialize (src/gpu/ipc/service/gpu_command_buffer_stub.cc) and creating a new gl::GLShareGroup if the share_command_buffer_stub is null, works around this bug.

I'm a little surprised this worked that easily -- doing this for all contexts broke Chrome's rendering, and it must be working because erikchen@ changed WebGL to prefer to use IOSurfaces for its back buffer, and these can be shared both across share groups and across processes.

CC'ing ANGLE folks as FYI. By the time MANGLE ships on macOS, hopefully 10.13 will have been out for a while so this sort of workaround won't be needed there.

erikchen / ccameron: how viable is a workaround of this form, where if the avoid_stencil_buffers driver bug workaround is active, we require the CHROMIUM_image path to be taken in DrawingBuffer::CreateColorBuffer? I don't remember whether there are situations where other content on the page would somehow cause the WebGL DrawingBuffer to fall back to the texture-backed path.

Just perusing through the code a bit, the only times CHROMIUM_image are disabled are via:

1) Developer flag/command line flag.
2) host()->IsOffscreenCanvas(). The latter appears to still be an experimental technology.

As such, I think that forcing CHROMIUM_image for the workaround [which is to say, disabling WebGL if CHROMIUM_image isn't available] seems acceptable.

Talked with ccameron@ and piman@ at length about this.

It's not quite as simple as this in the general case. It's necessary not just to display WebGL's back buffer in the compositor, but also to support tex[Sub]Image2D from DOM sources. Some of these like canvases already prefer to use IOSurfaces as their backing stores, but not all.

It may be possible to add a new MailboxManager implementation that is specialized for passing IOSurfaces between contexts, and which calls CGLTexImageIOSurface2D in the receiving context when it's not in the same share group as the sending context. (It would use the GLImage APIs, but would only be used on Mac.) When passing regular textures, it would need to blit both into and out of an IOSurface in order to get a TEXTURE_2D texture on the other side.

macOS' OpenGL implementation has constraints like global flush ordering that would probably make this tractable. On other OSs, the cross-context sharing mechanisms have restrictions that make it hard to implement mailboxes' semantics. So any workaround like this would be heavily Mac-specific.

piman@ suggested to investigate whether Maps is allocating stencil buffers itself or whether the WebGL back buffer is leaking, which could inform a different workaround. Investigating that now.

Per logging, Maps is allocating its own depth/stencil renderbuffer (of type GL_DEPTH_STENCIL_OES) and attaching it to the GL_DEPTH_STENCIL_ATTACHMENT attachment point. Therefore, it would not work -- at least not easily -- to try to lazily allocate the stencil buffer.

The only feasible workaround at this point is to track the total amount of memory allocated for depth/stencil renderbuffers, computing an approximation of the amount of memory that has leaked at any point in time, and restarting the GPU process when all WebGL contexts have been released and the leak is more than a certain amount.

This week I'll be working with the Montreal team and unable to move this bug forward. If someone would like to take it and implement the above workaround please feel free.

The only possible workaround for this is fairly drastic and I think that the stencil buffer leak associated with Google Maps is probably not the top issue affecting users. Consequently I'm downgrading this to P2.

This bug was fixed in Apple's graphics driver for 10.13. It's not worth the engineering effort to try to work around the bug in earlier OS releases.