It's always been you, Canvas2D

Re:It's always been you, Canvas2D by kllrnohj on Friday March 04, 2022 @11:35AM (#30556969)

PBOs allow for asynchronous readbacks from opengl. It's not slow because of the pcie bus (heck for most devices this is unified memory in the first place, it doesn't hit any bus other than dram). Rather it's slow for the same reason glFinish() is. You're blocking waiting for the results of the asynchronous rendering which you probably also just kicked off right at that point.

Also it's not like the opengl is happening on the same thread as the canvas2d (or even the same process), so that's yet more synchronization that a blocking getImageData needs to wait on.

[ Parent | on HN ]

Re:It's always been you, Canvas2D by dahart on Friday March 04, 2022 @11:48AM (#30557147)

Yeah, exactly, that’s what I’m curious about - if the browser’s renderer is adding significant amounts of delay due to additional synchronization, or if the problem with canvas.getImageData() is the same problem we’ve always had and if the delays are similar. This does make it seem like a callback to receive last frame’s image could be much faster than a synchronous read call, and I’d certainly use that if it existed…

[ Parent | on HN ]

Re:It's always been you, Canvas2D by kllrnohj on Saturday March 05, 2022 @05:05PM (#30572402)

canvas.getImageData() would have gotten a lot slower as GPU acceleration of Canvas2D became increasingly more common. The initial versions of Canvas2D were all software rasterized, which means getImageData() likely didn't involve any IPCs and definitely didn't involve any GPU readbacks. It was just a memcpy if that.

[ Parent | on HN ]