WebGLLayerChromium will need to keep its own context for drawing, but will need to use a compositor context passed in as a function arg during updateCompositorResources. Similarly to bug 66435, the interaction with adding and removing child contexts from the LayerRendererChromium will need to be deferred. The part that I don't fully understand is how to handle WebGLLayerChromium::paintRenderingResultsToCanvas. That seems problematic at best to get working with the compositor thread.
Yeah it's extremely problematic. It's basically a hack to get printing going for m14. We need to figure this out for real going forward.
I personally vote that we punt on threaded compositor + WebGL + printing for now. It'll be a pain to sort out now, but I think it'll become more clear once we figure out how we handle readback paths in the threaded compositor in general.
(In reply to comment #2) > I personally vote that we punt on threaded compositor + WebGL + printing for now. It'll be a pain to sort out now, but I think it'll become more clear once we figure out how we handle readback paths in the threaded compositor in general. In the short term maybe we can #ifdef this functionality out when the threaded compositor is on and file another bug to fix it properly.
This was fixed in bug 66430.