What would you conclude from this? Is it worth the effort to use canvas-as? Or should we just stick to JS (and keep in mind those performance tricks you mentioned like not repeating fills, etc)?
So far, what I've honestly seen is very little love for CanvasRenderingContext2D. Most of us who use it aren't making fully fledged 2d games. (some of us are, but I don't think they are majority)
One of the major takeaways was that minimizing draw calls, as you state, was the most important thing to optimize. It's not just draw calls either. Setting fillStyle and strokeStyle values call into the color parser. Preventing the need to parse colors can add up to a relatively big deal.
One thing is for certain. If you need Javascript, then it's probably important to just let v8 and Firefox compile your Javascript. I mean this sincerely and honestly as an AssemblyScript evangelist***.
In the case of, say, an engine, it might be more wise to use a compiled to web assembly solution. When assemblyscript gets reference counting and garbage collection, things are going to be very very different! But for now? I think regular js is a perfectly valid solution.
Testing is probably the only way to get the "best" solution. If you can minimize cpu usage and avoid calling into and out from wasm often, it might be worth it. Reduced garbage collection time is always worth looking into.
So, it seems like the trade off isn't huge, at least for the that use case (f.e. it isn't doing lots of number crunching, just organizing/optimizing calls to the canvas).
But, you mentioned that size of GC invocations was reduced, and the invocations happened more often. Does this at least reduce the "jank", the periodic pauses, so that the app performs more consistently over time, thus user experience can be improved? If so, maybe that alone is worth it. Thoughts on that?
Yes that was my exact conclusion. Web Assembly is only going to get better, and soon, when multivalue returns and reftypes are supported, the bridge between Javascript and web assembly will be very short to cross.
As for web assembly using webgl, the linked functions you use will require a large amount of Javascript glue, just like as2d. Please feel free to delve in and get your hands dirty. I am interested to see how far the rabbit hole goes.
Cool. I think I'm going to take Babylon.js, which is already in TypeScript, and start by porting a minimal set of features over in order to get cubes rendering on screen as a PoC.
Mostly I think it'll be converting numbers to i* types, and editing the renderer so that is connects with the JS glue to a canvas.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What would you conclude from this? Is it worth the effort to use canvas-as? Or should we just stick to JS (and keep in mind those performance tricks you mentioned like not repeating fills, etc)?
So far, what I've honestly seen is very little love for CanvasRenderingContext2D. Most of us who use it aren't making fully fledged 2d games. (some of us are, but I don't think they are majority)
One of the major takeaways was that minimizing draw calls, as you state, was the most important thing to optimize. It's not just draw calls either. Setting fillStyle and strokeStyle values call into the color parser. Preventing the need to parse colors can add up to a relatively big deal.
One thing is for certain. If you need Javascript, then it's probably important to just let v8 and Firefox compile your Javascript. I mean this sincerely and honestly as an AssemblyScript evangelist***.
In the case of, say, an engine, it might be more wise to use a compiled to web assembly solution. When assemblyscript gets reference counting and garbage collection, things are going to be very very different! But for now? I think regular js is a perfectly valid solution.
Testing is probably the only way to get the "best" solution. If you can minimize cpu usage and avoid calling into and out from wasm often, it might be worth it. Reduced garbage collection time is always worth looking into.
Edit: please check out github.com/as2d/as2d and use github.com/jtenner/as-pect for your testing if you decide to jump down the rabbit hole to see how far it goes.
Nice projects!
I'm thinking to make an AS WebGL experiment.
So, it seems like the trade off isn't huge, at least for the that use case (f.e. it isn't doing lots of number crunching, just organizing/optimizing calls to the canvas).
But, you mentioned that size of GC invocations was reduced, and the invocations happened more often. Does this at least reduce the "jank", the periodic pauses, so that the app performs more consistently over time, thus user experience can be improved? If so, maybe that alone is worth it. Thoughts on that?
Yes that was my exact conclusion. Web Assembly is only going to get better, and soon, when multivalue returns and reftypes are supported, the bridge between Javascript and web assembly will be very short to cross.
As for web assembly using webgl, the linked functions you use will require a large amount of Javascript glue, just like as2d. Please feel free to delve in and get your hands dirty. I am interested to see how far the rabbit hole goes.
I fear how much time the rabbit hole will take to explore, but if the results are worth it...
I'm guessing having a scene graph 🌲 structure (thinking something like Three.js) and doing all the matrix updates in Wasm would show some gain.
Then on the JS side it would need to get the list of objects/commands to render from wasm, which could be in a typed array in some format.
If you decide to venture, I'll join you on your quest! Good luck.
Cool. I think I'm going to take Babylon.js, which is already in TypeScript, and start by porting a minimal set of features over in order to get cubes rendering on screen as a PoC.
Mostly I think it'll be converting numbers to i* types, and editing the renderer so that is connects with the JS glue to a canvas.