To be honest, there's no particular reason for using D3, I just wanted to try out the library on a non-guided example. You could easily just take the list of cells and just draw circles and a polyline, and it would have resulted in about the same amount of code.
Hoo, boy... there's an entire book to write on that topic. Honestly, it doesn't matter while your performance is acceptable for your intended audience.
It depends on how efficient you require the code to be. Does it have to run at huge resolutions on tiny devices, or is it just a framerate insensitive toy to be run on the desktop? Depending on those factors, you might want to consider a general mechanism (SVG vs. 2D canvas vs. WebGL vs. generating byte arrays in WASM, etc.), then choose the library that can perform that, depending on your workload.
I usually choose something I can cleanly express my problem in, and if that becomes a bottleneck, I build the code in such a way that the rendering is completely decoupled from the library, so I can switch it out for anything else in the future.
And just to note, the bottleneck in this simulation is the inefficient O(n^2) requirement for calculating forces between non-connected cells. The rendering is really not the slowest part of this algorithm. You'd have to look into things like space partitioning (quadtrees) and offloading calculations to the GPU (GPGPU) to ever reach speeds that would make rendering the bottleneck. So in this case, it really doesn't matter what I use for rendering, as rendering will grow approximately linearly with the number of particles (O(n)).
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.
Thank you!
To be honest, there's no particular reason for using D3, I just wanted to try out the library on a non-guided example. You could easily just take the list of cells and just draw circles and a polyline, and it would have resulted in about the same amount of code.
Ok, I just wanted to know if you've seen any benefit over other possibilities (p5, Pencil.js, your own lib ...)
Hoo, boy... there's an entire book to write on that topic. Honestly, it doesn't matter while your performance is acceptable for your intended audience.
It depends on how efficient you require the code to be. Does it have to run at huge resolutions on tiny devices, or is it just a framerate insensitive toy to be run on the desktop? Depending on those factors, you might want to consider a general mechanism (SVG vs. 2D canvas vs. WebGL vs. generating byte arrays in WASM, etc.), then choose the library that can perform that, depending on your workload.
I usually choose something I can cleanly express my problem in, and if that becomes a bottleneck, I build the code in such a way that the rendering is completely decoupled from the library, so I can switch it out for anything else in the future.
And just to note, the bottleneck in this simulation is the inefficient
O(n^2)requirement for calculating forces between non-connected cells. The rendering is really not the slowest part of this algorithm. You'd have to look into things like space partitioning (quadtrees) and offloading calculations to the GPU (GPGPU) to ever reach speeds that would make rendering the bottleneck. So in this case, it really doesn't matter what I use for rendering, as rendering will grow approximately linearly with the number of particles (O(n)).