Bug 107804

Summary: [mac] ImageBuffer should create accelerated buffers for small canvases, but we shouldn't force them to create compositing layers
Product: WebKit Reporter: Tim Horton <thorton>
Component: CanvasAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, buildbot, eric, ojan.autocc, rniwa, sam, simon.fraser, webkit.review.bot
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 108310    
Bug Blocks:    
Attachments:
Description Flags
patch
simon.fraser: review-, buildbot: commit-queue-
patch
none
patch
simon.fraser: review-
Simon really doesn't like it when you touch Platform.h simon.fraser: review+

Tim Horton
Reported 2013-01-24 01:45:50 PST
<rdar://problem/11752381> Mac WebKit is slower than it needs to be on http://www.mikechambers.com/html5/javascript/QuadTree/examples/collision.html because it makes lots of tiny canvases and draws them into a big one. The tiny ones fall below ImageBufferCG's "minIOSurfaceSize", so they are created in main memory. The big one is big, so it's an IOSurface. Painting between these is incredibly slow. The reason we cap ImageBuffer acceleration by size is so that small canvases (for example, http://typeface.neocracy.org/examples.html) don't force compositing (and then potentially cause overlap, and huge memory cost). But, we can still make IOSurfaces and still not pop them into compositing layers. So, let's do that!
Attachments
patch (3.56 KB, patch)
2013-01-24 01:52 PST, Tim Horton
simon.fraser: review-
buildbot: commit-queue-
patch (4.18 KB, patch)
2013-01-30 14:40 PST, Tim Horton
no flags
patch (4.83 KB, patch)
2013-01-30 14:43 PST, Tim Horton
simon.fraser: review-
Simon really doesn't like it when you touch Platform.h (3.90 KB, patch)
2013-01-30 14:57 PST, Tim Horton
simon.fraser: review+
Tim Horton
Comment 1 2013-01-24 01:52:55 PST
Created attachment 184441 [details] patch name of the constant is a little wonky
Tim Horton
Comment 2 2013-01-24 01:54:14 PST
Comment on attachment 184441 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=184441&action=review > Source/WebCore/rendering/RenderLayerCompositor.cpp:1907 > + return canvas->renderingContext() && canvas->renderingContext()->isAccelerated() && (canvas->size().area() > canvasAreaThresholdRequiringCompositing); This is shared code, I wonder if this is reasonable for everyone...
Build Bot
Comment 3 2013-01-24 05:09:15 PST
Comment on attachment 184441 [details] patch Attachment 184441 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16082655 New failing tests: fast/canvas/webgl/gl-pixelstorei.html fast/canvas/webgl/tex-image-webgl.html compositing/layer-creation/spanOverlapsCanvas.html
Simon Fraser (smfr)
Comment 4 2013-01-24 08:38:46 PST
Comment on attachment 184441 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=184441&action=review >> Source/WebCore/rendering/RenderLayerCompositor.cpp:1907 >> + return canvas->renderingContext() && canvas->renderingContext()->isAccelerated() && (canvas->size().area() > canvasAreaThresholdRequiringCompositing); > > This is shared code, I wonder if this is reasonable for everyone... We should probably #ifdef it. Maybe USE_COMPOSITING_FOR_SMALL_CANVASES or something, disabled for PLATFORM(MAC) and PLATFORM(IOS).
Tim Horton
Comment 5 2013-01-24 10:52:00 PST
(In reply to comment #3) > (From update of attachment 184441 [details]) > Attachment 184441 [details] did not pass mac-ews (mac): > Output: http://queues.webkit.org/results/16082655 > > New failing tests: > fast/canvas/webgl/gl-pixelstorei.html > fast/canvas/webgl/tex-image-webgl.html ... not a clue, but I can reproduce, so I'll look. > compositing/layer-creation/spanOverlapsCanvas.html This one uses a canvas at exactly the threshold and demonstrates that I should have used >= instead of > to match the < from before.
Tim Horton
Comment 6 2013-01-30 14:40:23 PST
Tim Horton
Comment 7 2013-01-30 14:42:22 PST
Needs a WTF changelog.
Tim Horton
Comment 8 2013-01-30 14:43:28 PST
Simon Fraser (smfr)
Comment 9 2013-01-30 14:54:54 PST
Comment on attachment 185582 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=185582&action=review > Source/WTF/wtf/Platform.h:1218 > +#if !PLATFORM(MAC) && !PLATFORM(IOS) > +#define WTF_USE_COMPOSITING_FOR_SMALL_CANVASES 1 > +#endif Please don't cause megawatts of energy use in making us all rebuild because of this #ifdef that's only used in one place.
Tim Horton
Comment 10 2013-01-30 14:57:52 PST
Created attachment 185589 [details] Simon really doesn't like it when you touch Platform.h
Simon Fraser (smfr)
Comment 11 2013-01-30 15:05:47 PST
Comment on attachment 185589 [details] Simon really doesn't like it when you touch Platform.h View in context: https://bugs.webkit.org/attachment.cgi?id=185589&action=review > Source/WebCore/rendering/RenderLayerCompositor.cpp:1921 > + bool isCanvasLargeEnoughToForceCompositing = canvas->size().area() >= canvasAreaThresholdRequiringCompositing; Hmm, this looks at element size. Maybe we should composite based on the renderer dimensions? You might have a small canvas scaled up via CSS.
Simon Fraser (smfr)
Comment 12 2013-01-30 15:33:20 PST
Comment on attachment 185589 [details] Simon really doesn't like it when you touch Platform.h I think this is fine.
Tim Horton
Comment 13 2013-01-30 15:36:39 PST
Note You need to log in before you can comment on or make changes to this bug.