66439 2011-08-17 17:46:47 -0700 [chromium] Remove LayerRendererChromium references from WebGLLayerChromium 2011-09-02 11:19:16 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 66430 1 enne webkit-unassigned enne husky jamesr kbr nduca oldest_to_newest 452768 0 enne 2011-08-17 17:46:47 -0700 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. 452769 1 jamesr 2011-08-17 17:48:51 -0700 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. 453151 2 jamesr 2011-08-18 11:05:50 -0700 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. 453155 3 enne 2011-08-18 11:09:21 -0700 (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. 461357 4 enne 2011-09-02 11:19:16 -0700 This was fixed in bug 66430.