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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Jan 8 01:51:11 PST 2022


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

--- Comment #1 from Simon Taylor <simontaylor1 at ntlworld.com> ---
Here is an example page:
https://tango-bravo.net/webkit-bug-235002/index.html

A video element is uploaded to a texture with texImage2d, then rendered to fill the first canvas.

Two different readPixel approaches are then applied, firstly via a PIXEL_PACK_BUFFER, then directly to an ArrayBuffer.

To confirm the data (from the first, faster, method) is correct, it is uploaded with texImage2d to a second WebGL context and rendered there too.

In Safari 15.2 (both iOS and macOS) the direct readPixels is significantly slower.

The page shows average timings every 60 frames - the "readPixels (with buffer)" timings separate out the (very fast) readPixels and the (blocking) getBufferSubData.

Note the PIXEL_PACK_BUFFER readPixels happens first, so all of the time spent waiting for GPU completion is accounted for in the getBufferSubData timings. Even with that, the direct readPixels is typically 3x slower on both iPhone 12 and M1 Pro MacBook.

Typical iPhone 12 timings:

Total Draw Time: 8.97 ms 
Upload from video: 0.67 ms 
readPixels (with buffer): 0.12 + 1.92 ms 
readPixels (direct): 6.07 ms 
Render loop: 59.88 fps

-- 
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/20220108/c641540f/attachment.htm>


More information about the webkit-unassigned mailing list