[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 #6 from Simon Taylor <simontaylor1 at ntlworld.com> ---
I've made some updates to the test page.
https://tango-bravo.net/webkit-bug-235002/index.html

I took Kimmo's suggestion to add gl.finish() after submitting drawing commands, and have pulled out a few more individual timing measurements. NB: Anything <1ms should be taken with a pinch of salt as that's the performance.now() granularity.

There's now a checkbox to busy loop at the end of rAF function which ensures the callback takes 20ms - this triggers the scheduler to keep the content thread on a Performance core with high clocks, and makes the timings more comparable between different options (otherwise more efficient options end up taking longer as the device can lower clocks whilst maintaining 60FPS).

There's also a microbenchmark for how many calls to Math.random() can be made in a single performance.now() tick (ie 1ms) - the idea is to  gives a proxy for CPU frequency, and to give additional confidence the busy loop is successful at triggering consistently high clocks. [iOS 15.2 has a little extra weirdness there as that number increases a lot when switching away from the tab and back again - from ~11k with busy loop enabled to ~30k. 14.8.1 gives ~30k from the start. Expect a new bug soon on that...]

With those intros out of the way, on to the main finding - having a texture-backed framebuffer bound makes the direct-to-ArrayBuffer readPixels MUCH faster on the iOS 15.2 Metal backend (from ~4.5ms to <0.5ms). It looks like that row-by-row readPixels implementation is avoided in that case.

The page now also works on browsers that only have webgl1, to allow investigating iOS 14 performance too - I tried with 14.8.1 which I believe uses ANGLE but with the GL backend. Only direct-to-ArrayBuffer readPixels is supported there. Timings appear to be the other way around - a readPixels from the default framebuffer is a bit faster (1.5x or so) than from a texture-backed framebuffer, but both are much slower than the iOS 15 backend.

In summary, readPixels is absolutely smoking fast on iOS 15, as long as it isn't a direct-to-ArrayBuffer readPixels from the default canvas framebuffer. Nice work everyone!

-- 
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/20220112/33776499/attachment-0001.htm>