Bug 80450 - [chromium] REGRESSION(109469): WebGL printing busted
Summary: [chromium] REGRESSION(109469): WebGL printing busted
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: James Robinson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-06 16:04 PST by James Robinson
Modified: 2012-03-06 17:08 PST (History)
3 users (show)

See Also:


Attachments
Patch (2.01 KB, patch)
2012-03-06 16:55 PST, James Robinson
kbr: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Robinson 2012-03-06 16:04:41 PST
Post r109469 printing WebGL fails, nothing shows up.
Comment 1 James Robinson 2012-03-06 16:48:44 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.
Comment 2 James Robinson 2012-03-06 16:55:52 PST
Created attachment 130476 [details]
Patch
Comment 3 Kenneth Russell 2012-03-06 17:02:07 PST
Comment on attachment 130476 [details]
Patch

LGTM as long as it's been tested.
Comment 4 James Robinson 2012-03-06 17:04:54 PST
I've manually tested WebGL printing and run the layout / unit tests and things seem to work. Fingers crossed!
Comment 5 James Robinson 2012-03-06 17:08:27 PST
Committed r109982: <http://trac.webkit.org/changeset/109982>