| Summary: | [chromium] REGRESSION(109469): WebGL printing busted | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | James Robinson <jamesr> | ||||
| Component: | New Bugs | Assignee: | James Robinson <jamesr> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | cc-bugs, jbauman, kbr | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
James Robinson
2012-03-06 16:04:41 PST
The issue here appears to be switching from using contentChanged() to setNeedsDisplay...() to set the m_textureUpdated bit on WebGLLayerChromium. That bit is used to implement preservesDrawingBuffer semantics, so it's important that it is only set due to a WebGL draw. Unfortunately when printing we synchronously rebuild the compositing tree which triggers a call to GraphicsLayerChromium::setContentsToCanvas() which calls setNeedsDisplay() on the m_contentsLayer. I have no idea why it does this, but that's what breaks printing. I'm pretty confident the fix is to not call setNeedsDisplay() in GLC::setContentsToCanvas(), at least if the new layer == the old one. Created attachment 130476 [details]
Patch
Comment on attachment 130476 [details]
Patch
LGTM as long as it's been tested.
I've manually tested WebGL printing and run the layout / unit tests and things seem to work. Fingers crossed! Committed r109982: <http://trac.webkit.org/changeset/109982> |