[Webkit-unassigned] [Bug 66834] New: [chromium] Handle concurrent compositing and canvas 2d rendering in the threaded world

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66834

           Summary: [chromium] Handle concurrent compositing and canvas 2d
                    rendering in the threaded world
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jamesr at chromium.org
                CC: fishd at chromium.org, reed at google.com,
                    senorblanco at chromium.org, vangelis at chromium.org,
                    enne at google.com, nduca at chromium.org


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.