RESOLVED FIXED 58907
[chromium] Don't unnecessarily resize skia/cg canvases when painting in compositor
https://bugs.webkit.org/show_bug.cgi?id=58907
Summary [chromium] Don't unnecessarily resize skia/cg canvases when painting in compo...
Adrienne Walker
Reported 2011-04-19 11:07:16 PDT
[chromium] Don't unnecessarily resize skia/cg canvases when painting in compositor
Attachments
Patch (3.47 KB, patch)
2011-04-19 11:09 PDT, Adrienne Walker
no flags
Patch (7.69 KB, patch)
2011-04-27 14:01 PDT, Adrienne Walker
jamesr: review+
jamesr: commit-queue-
Adrienne Walker
Comment 1 2011-04-19 11:09:25 PDT
Adrienne Walker
Comment 2 2011-04-19 11:10:44 PDT
James brought up this issue during a code inspection of how LayerTilerChromium worked, but when looking into fixing it, it looked like the save and restore context logic wasn't correct either.
Adrienne Walker
Comment 3 2011-04-19 11:12:05 PDT
Comment on attachment 90220 [details] Patch Actually, I'd like to write a layout test for this. I only caught the context save/restore logic snafu because I manually tested this two line patch. So, I'm taking off request for review until I do that.
Adrienne Walker
Comment 4 2011-04-27 14:01:03 PDT
James Robinson
Comment 5 2011-04-27 14:08:04 PDT
I'm not sure I understand the save/restore context stuff here - could you explain? What was wrong with the previous code?
Adrienne Walker
Comment 6 2011-04-27 14:11:36 PDT
The previous code (and the reason for including this test case) put the save and restore in the wrong place. In LayerTilerChromium, there's a translation of the canvas as well which wasn't getting popped. So, multiple redraws of the same canvas would accumulate an incorrect transform. This was masked because we were always recreating the canvas. Oops. The save/restore was moved to be in the Painter functor itself, where it can wrap all state changing operations.
James Robinson
Comment 7 2011-04-28 15:38:18 PDT
Comment on attachment 91343 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=91343&action=review R=me, few things to address before landing. > LayoutTests/compositing/repaint/same-size-invalidation.html:22 > + setTimeout("changeBackground1();", 0); nit: setTimeout(changeBackground1, 0) is a bit better. move doTest below the declarations of the functions. > LayoutTests/platform/chromium/test_expectations.txt:3973 > +BUGENNE : compositing/repaint/same-size-invalidation.html = FAIL = FAIL isn't sufficient - these will fail with MISSING on windows and mac since there is no baseline for those platforms. This test should render the same on all platforms so I'd just check same-size-invalidation-expected.png/checksum into platform/chromium-gpu/ and not modify test_expectations at all. > Source/WebCore/platform/graphics/chromium/PlatformCanvas.h:84 > + // Destructor restores canvas to pre-construction state. does the Painter manipulate any state on the PlatformCanvas? Painter::Painter() and Painter::~Painter() only seem to mutate their m_context, which doesn't do anything to the PlatformCanvas other than render into it.
Adrienne Walker
Comment 8 2011-04-28 19:38:27 PDT
(In reply to comment #7) > (From update of attachment 91343 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=91343&action=review > > R=me, few things to address before landing. > > > LayoutTests/compositing/repaint/same-size-invalidation.html:22 > > + setTimeout("changeBackground1();", 0); > > nit: setTimeout(changeBackground1, 0) is a bit better. move doTest below the declarations of the functions. Will do. Using a string is just sloppy. Also, I don't think I need to reorder anything because Javascript hoisting will take care of it. > > LayoutTests/platform/chromium/test_expectations.txt:3973 > > +BUGENNE : compositing/repaint/same-size-invalidation.html = FAIL > > = FAIL isn't sufficient - these will fail with MISSING on windows and mac since there is no baseline for those platforms. Yeah, I've changed this locally already. I learned that the hard way just yesterday. > This test should render the same on all platforms so I'd just check same-size-invalidation-expected.png/checksum into platform/chromium-gpu/ and not modify test_expectations at all. Too much gardening experience lately has made me cautious. I was going to let the rebaseline tool tell me that. > > Source/WebCore/platform/graphics/chromium/PlatformCanvas.h:84 > > + // Destructor restores canvas to pre-construction state. > > does the Painter manipulate any state on the PlatformCanvas? Painter::Painter() and Painter::~Painter() only seem to mutate their m_context, which doesn't do anything to the PlatformCanvas other than render into it. Perhaps the comment should be clarified to be "restores canvas context" instead.
Adrienne Walker
Comment 9 2011-05-02 15:13:49 PDT
Adrienne Walker
Comment 10 2011-05-02 16:13:35 PDT
Note You need to log in before you can comment on or make changes to this bug.