For the initial benchmark:
> Over the 2 minute measured timespan, there was only 14% less CPU usage than with 2.9, tested over a number of trials.
> Also, the red dots in the timeline at the top indicate blocked frames, or frame skips.
In terms of power usage, 14% less CPU while instead using GPU for rendering probably leads to
an actual higher power usage. Also, if the frame was skipped/blocked while waiting for the GPU, this can also explain the less CPU usage (CPU was idle as it was waiting for the GPU). My point is, this was not necessarily an improvement, especially considering that frame skips are the worst that can happen.
I think a more fair comparison would have been to compare WebGL in JS vs WebGL through AssemblyScript, not Canvas2D vs WebGL in AssemblyScript, as now parts of the improvements come from moving computation from CPU to GPU, not necessarily from using WebAssembly. This is mentioned in the conclusion: "Are the performance gains of the new version fully attributable to WebAssembly? Most likely not.".
> 65% less CPU used than in 2.9
This is amazing. It would be good to also check the GPU usage delta.
> Don't use unnecessary WebWorkers
The thing about WebWorkers is that you have to be really careful with memory transfer, and use transferable objects only to avoid memory copying.
It would be also interested to see if using OffscreenCanvas can lead to better performance for this high-res image use-case.
> I could gzip them before base64-encoding them
This was a clever solution but doesn't the extra JS parsing (for the new library) and CPU usage (for decoding the file) take more time than the original solution?
As I said in the article about the benchmarking-- I definitely did it the "quick and dirty" way, testing the whole application 2.9 vs 3.0 on just my device-- not testing specifically for difference in power usage, GPU usage, etc. I would love to have time/resources enough to more microtests as you describe.
Micrio used OffscreenCanvas for a long time. Turns out (apart from occasional flickering screens in Safari) while it did great for Canvas2D operations, it didn't seem to make a difference for WebGL. It actually adds more rendering steps, since you're basically rendering to a framebuffer first.
As someone else pointed out below, with loading the textures using WebWorkers, I indeed didn't use the transferable objects, so it was basically copying a lot of buffers, explaining the performance hits. I'll definitely be experimenting with that.
About the gzipping solution; I've just run a benchmark. It takes 14ms to gunzip & parse the JS base64 to ES6 string, and 59ms to run it inside the `new Function()`-parser. Comparing that to 65% CPU saved per frame drawn (not to mention the general V8 ES6 optimizations compared to the previous ES5 JS-version), I think the cost is worth it :)
For the initial benchmark: > Over the 2 minute measured timespan, there was only 14% less CPU usage than with 2.9, tested over a number of trials. > Also, the red dots in the timeline at the top indicate blocked frames, or frame skips.
In terms of power usage, 14% less CPU while instead using GPU for rendering probably leads to an actual higher power usage. Also, if the frame was skipped/blocked while waiting for the GPU, this can also explain the less CPU usage (CPU was idle as it was waiting for the GPU). My point is, this was not necessarily an improvement, especially considering that frame skips are the worst that can happen.
I think a more fair comparison would have been to compare WebGL in JS vs WebGL through AssemblyScript, not Canvas2D vs WebGL in AssemblyScript, as now parts of the improvements come from moving computation from CPU to GPU, not necessarily from using WebAssembly. This is mentioned in the conclusion: "Are the performance gains of the new version fully attributable to WebAssembly? Most likely not.".
> 65% less CPU used than in 2.9
This is amazing. It would be good to also check the GPU usage delta.
> Don't use unnecessary WebWorkers
The thing about WebWorkers is that you have to be really careful with memory transfer, and use transferable objects only to avoid memory copying.
It would be also interested to see if using OffscreenCanvas can lead to better performance for this high-res image use-case.
> I could gzip them before base64-encoding them
This was a clever solution but doesn't the extra JS parsing (for the new library) and CPU usage (for decoding the file) take more time than the original solution?