Bug 66834

Summary: [chromium] Handle concurrent compositing and canvas 2d rendering in the threaded world
Product: WebKit Reporter: James Robinson <jamesr>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: enne, fishd, nduca, reed, robin.webkit, schenney, senorblanco, vangelis
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

James Robinson
Reported 2011-08-23 18:46:26 PDT
Today in the gpu canvas 2d case we have a pretty simple cross-context synchronization mechanism - we do a ganesh and context flush on the canvas 2d context and then do a draw using the DrawingBuffer's fbo's color attachment as the source from the compositor context. This is very efficient (no extra copies) but it relies on the fact that after calling Canvas2DLayerChromium::updateCompositorResources() we do no more canvas draws until after the compositor is done. This works in the current single-threaded compositor since the pattern is to call updateCompositorResources() on all layers then do a draw before yielding to the event loop. In the threaded world this doesn't work any more, since we'll continue doing composites from the compositing thread while the main thread continues running javascript. We need to make sure that draw calls made by canvas do not show up in the composited output until the next commit and call to updateCompositorResources(). The copy-to-parent-texture mechanism used to have this property, although it did a wasteful copy on every frame. The options are either: 1.) avoid mutating the DrawingBuffer's fbo's color attachment until the next commit, perhaps by queuing canvas 2d draw calls in an SkPicture 2.) do a copy of the color attachment in updateCompositorResources() so the compositor can always use the previous frame while javascript works on the next frame or some clever combination. I think to start the easiest thing to do is to add a copy-on-dirty mechanism to Canvas2DLayerChromium::updateCompositorResources and always expose a copy rather than a live texture to the compositor's context. We could try to get cleverer and have a fully copy-on-write mechanism in DrawingBuffer but that might get hairy. I'd like to do this in a way that does not introduce too many unnecessary copies but that might be difficult in the general case.
Attachments
Note You need to log in before you can comment on or make changes to this bug.