[Webkit-unassigned] [Bug 49999] New: better V8 bindings for HTML5 ImageData

[bugzilla-daemon at webkit.org]

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

           Summary: better V8 bindings for HTML5 ImageData
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: yuqiang.xian at intel.com
                CC: iposva at chromium.org, vitalyr at chromium.org


Details please see the Chromium bug - http://code.google.com/p/chromium/issues/detail?id=3473.

V8 has already avoided the CanvasPixelArray element access through the C++ bindings by introducing a PixelArray class in V8 space (http://code.google.com/p/v8/source/detail?r=2549, http://trac.webkit.org/changeset/46495). 

Actually we can go further. Currently V8 still needs to wrap the CanvasPixelArray object through the C++ bindings, and it's still a big performance issue in some cases like the below example -

frame = context.getImageData(0, 0, canvas.width, canvas.height);
…    
for (var i = 0; i < frame.data.length; i += 4) {
    var r = frame.data[i + 0];
    var g = frame.data[i + 1];
    var b = frame.data[i + 2];

    var v = r + g + b;
    v /= 3;

    frame.data[i + 0] = v;
    frame.data[i + 1] = v;
    frame.data[i + 2] = v;
}    
…    
context.putImageData(frame, 0, 0);

There’ll be frequent invocations from Jitted code to native C++ code and big overhead for object bindings for “frame.data” access. Every “frame.data” access in the loop runs into the object binding code, which then lookups the hash map maintaining the relationship between DOM objects and the corresponding V8 objects, and returns the V8 object for “data” (a CanvasPixelArray object wrapper), and thus the object bindings overhead comes out. 

We can create a normal V8 object which has a PixelArray as the backing storage, and set the "data" property of ImageData object to it. This way we don't need to call through the C++ bindings for ImageData "data" access. This eliminates big overhead in switching between JavaScript and native contexts and performing object bindings when there're frequent "data" property accesses of ImageData.

This is also similar to the approach how JSC handles ImageData.

Back to the example case again, we see >3X performance with the proposed change, when handling a 800x600 sized canvas.

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