| Summary: | WebGL in CSS Canvas crashes | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> | ||||||
| Component: | WebGL | Assignee: | Chris Marrin <cmarrin> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | cmarrin, jamesr, kbr, zmo | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Mac | ||||||||
| OS: | OS X 10.5 | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 30722 | ||||||||
| Attachments: |
|
||||||||
Why do we support CSS canvases in WebKit? Is this a regression or has this always crashed? (In reply to comment #1) > Why do we support CSS canvases in WebKit? We invented it. > Is this a regression or has this always crashed? It has never worked with a WebGL canvas. *** Bug 30722 has been marked as a duplicate of this bug. *** The above test is one use case of the feature. We need to add a set of tests when this bug is fixed to handle all the other use cases as well. Created attachment 65764 [details]
Patch with test cases
Cool! One minor request: can the tests be made dumpAsText() with javascript querying that the rendering result is correct? Maintaining platform-specific image results is a pain and it doesn't seem strictly necessary in this case. (In reply to comment #7) > Cool! One minor request: can the tests be made dumpAsText() with javascript querying that the rendering result is correct? Maintaining platform-specific image results is a pain and it doesn't seem strictly necessary in this case. Oops, I just realized that you couldn't verify that the background showed up correctly with a pure script test. Never mind, disregard comment #7 please :) Comment on attachment 65764 [details] Patch with test cases > Index: WebCore/ChangeLog > =================================================================== > + * html/HTMLCanvasElement.cpp: > + (WebCore::HTMLCanvasElement::copiedImage): Add logic to get image from WebGL so it works with Hyatt's new ImageBuffer logic This comment will not make any sense in a few months. Be more specific about what hyatt's changes were. Also, why didn't we see any other test bustage because of this? What would we have had to test to see breakage: drawing a 3d canvas into a 2d canvas? (In reply to comment #7) > Cool! One minor request: can the tests be made dumpAsText() with javascript querying that the rendering result is correct? Maintaining platform-specific image results is a pain and it doesn't seem strictly necessary in this case. I think it is necessary. I want to know that we are getting the correct rendering results, especially in the repaint test, which makes sure WebGL can modify the CSS background a second time. I know it's painful, but in this case I really think we need pixel tests. (In reply to comment #8) > (In reply to comment #7) > > Cool! One minor request: can the tests be made dumpAsText() with javascript querying that the rendering result is correct? Maintaining platform-specific image results is a pain and it doesn't seem strictly necessary in this case. > > Oops, I just realized that you couldn't verify that the background showed up correctly with a pure script test. Never mind, disregard comment #7 please :) Too late :-) Landed in http://trac.webkit.org/changeset/66258 |
Created attachment 62367 [details] Testcase Using WebGL in a CSS canvas (i.e. fetching the context via document.getCSSCanvasContext()) crashes. If I make a trivial fix for the crash, it still doesn't render.