[Webkit-unassigned] [Bug 235002] readPixels directly to ArrayBuffer has very high CPU usage

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Kimmo Kinnunen <kkinnunen at apple.com> ---
NOTE about the test case measurements:
The test case times are wrong, since the calls might not be completed when the caller side measurement is made.

Consider abstraction of the test case here:
        var s = MEASURE();
        gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, video);
        var upload = MEASURE() - s;

        s = MEASURE();
        gl.clear(gl.COLOR_BUFFER_BIT);
        gl.drawElements(gl.TRIANGLES, 6, gl.UNSIGNED_SHORT, 0);
        var draw = MEASURE() - s;

        s = MEASURE();
        gl.bindBuffer(gl.PIXEL_PACK_BUFFER, pixelBuffer);
        gl.readPixels(0, 0, 640, 360, gl.RGBA, gl.UNSIGNED_BYTE, 0);
        gl.getBufferSubData(gl.PIXEL_PACK_BUFFER, 0, pixels);
        var pack = MEASURE() - s;

        s = MEASURE();
        gl.readPixels(0, 0, 640, 360, gl.RGBA, gl.UNSIGNED_BYTE, pixelsDirect);
        var direct = MEASURE() - s;


The first blocking call is getBufferSubData, and as such the duration measurement "pack" might contain delay due to all the work submitted prior to that call.

The second blocking call duration readPixels will contain only the readPixels payload because it comes after a blocking call.

So a benchmark measuring individual gl sequeneces needs to call finish() before taking a measurement start timestamp and end in a blocking call, and needs to take the end timestamp after it.

        gl.finish();
        var s = MEASURE();
        gl.op();
        gl.op2();
        gl.readPixels();
        var dt = MEASURE() - s;

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220110/1da144cd/attachment.htm>