> There weren’t that many projectiles in the first place so I felt that this would be useful later. However, considering that Chrome and Safari were struggling performance wise probably due to their garbage collector working differently, I resigned myself to implement it now.
I'm curious about actual metrics with regard to Chrome / Safari's garbage collector overhead. You still don't have a lot of "objects" in the video; when V8 is used server side it handles significantly more objects. (IE, assuming each sword is 1-5 objects.)
Are these engines canvas based, or are they generating HTML? Assuming they are generating HTML, are the elements removed from the screen when you are done with them?
In a lot of garbage collected environments, you still need to call some kind of close / remove method when you are done with some kinds of objects. (In C#, it's "Dispose.")
> Additionally, to not disable batching it was important that all drawSprite calls be placed together in the draw loop before rendering text with drawText calls.
Sounds like reflow problems. And like OP is slowly discovering the 200% Problem.
I was able to find this comment, linking to a talk that coined(?) it. https://news.ycombinator.com/item?id=36091791 I guess in short you would say that learning a leaky simplifying abstraction actually increases the amount you have to learn.
Interesting writeup. It's surprising to me that the author was experiencing such severe performance issues with relatively simple scenes, and it sounds like the performance issues still aren't completely gone. In the past I've been able to run fairly complex 2D scenes in JS+canvas so I wonder if there's some sort of fundamental performance issue lurking underneath kaplay or some other library they're using?
> There weren’t that many projectiles in the first place so I felt that this would be useful later. However, considering that Chrome and Safari were struggling performance wise probably due to their garbage collector working differently, I resigned myself to implement it now.
I'm curious about actual metrics with regard to Chrome / Safari's garbage collector overhead. You still don't have a lot of "objects" in the video; when V8 is used server side it handles significantly more objects. (IE, assuming each sword is 1-5 objects.)
Are these engines canvas based, or are they generating HTML? Assuming they are generating HTML, are the elements removed from the screen when you are done with them?
In a lot of garbage collected environments, you still need to call some kind of close / remove method when you are done with some kinds of objects. (In C#, it's "Dispose.")
> Additionally, to not disable batching it was important that all drawSprite calls be placed together in the draw loop before rendering text with drawText calls.
Sounds like reflow problems. And like OP is slowly discovering the 200% Problem.
What is the 200% problem?
I was able to find this comment, linking to a talk that coined(?) it. https://news.ycombinator.com/item?id=36091791 I guess in short you would say that learning a leaky simplifying abstraction actually increases the amount you have to learn.
Interesting writeup. It's surprising to me that the author was experiencing such severe performance issues with relatively simple scenes, and it sounds like the performance issues still aren't completely gone. In the past I've been able to run fairly complex 2D scenes in JS+canvas so I wonder if there's some sort of fundamental performance issue lurking underneath kaplay or some other library they're using?