Bug 66439
| Summary: | [chromium] Remove LayerRendererChromium references from WebGLLayerChromium | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrienne Walker <enne> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | enne, husky, jamesr, kbr, nduca |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 66430 | ||
Adrienne Walker
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
James Robinson
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.
James Robinson
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.
Adrienne Walker
(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.
Adrienne Walker
This was fixed in bug 66430.