-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Canvas renderer #96
Comments
I have! In fact v1 of the library was implemented using a canvas. The issue ist that the canvas doesn't support 3D perspective transformations (atleast not with the transformation matrices - we could fake the effect by rendering our own meshes, triangle by triangle, but that seems like an awful lot of work, and I'm not even sure how much faster it would get). Additionally, if we restrict the users to canvas operations, they can no longer customize the shapes (easily) using CSS, which would make rendering and customization a bit tedious. That being said, since, like you said, it is a big performance hit for a lot of particles, and the implementation should be abstract enough to be agnostic of actual implementation, I am considering allowing users to switch between "fancy" (DOM/CSS) and "fast" (canvas) graphics in the next version of the library, if they want to squeeze out that extra bit of performance, at the cost of cheaper effects and less customizeability. I'd be happy to hear your thoughts on this! |
Performance wise using canvas gives a ~10x improvement over DOM particles. You can try it out yourself. Clone this repo and open canvas.html and dom.html: https://github.com/quidmonkey/particle_test You could fake the 3d rotation with the 2d canvas. Not that straightforward but you could achieve that with a single transform matrix, but yeah, the css styling would be lost |
I think the issue with implementing a toggleable fancy/fast rendering mode is that they require a completely different approach to particle shapes and styling. This is definitely tempting, but switching to a canvas now would break a lot of things and features that are nice to use. |
@volkyeth getting back to you on this a bit late (better late than never?), i'm currently planning the v3 rewrite of the library, and i'm thinking about switching to a canvas rendering mode to improve performance. 🎉 i might even try to go for a webgl approach, just to get the fancy rendering features, but that's still a bit in the clouds. if you have any input, i'd be happy to hear your opinions! |
@yiliansource def think a canvas renderer would be a huge improvement. CSS animations get sluggish pretty quickly with particle quantity Not sure about WebGL. I don't think this needs to go 3D to be fun...2.5D seems enough. It all boils down to performance, IMO. Not on par with current benchmarks, but whichever runs faster on mobile would be my pick. |
Did you ever think of implementing a
<canvas>
renderer?I love this lib and its simple API…much better than other bloated alternatives. The only issue with it is the performance, because of the DOM particles: With a couple hundreds of them it gets laggy, especially on mobile.
The text was updated successfully, but these errors were encountered: