Closed agurvich closed 2 years ago
My first googling seems to suggest that discarding and having conditionals is bad in general because it reduces the parallelism of the compiled shader. It may be worth having multiple fragment shaders and switching them in the main JS rather than using uniforms and conditionals to check (at least for stuff that is on a per mesh basis).
Not sure if that's a bad idea. It would be nice if we could just pass around compiled shaders rather than having to recompile whenever something was pressed in the UI.
[https://stackoverflow.com/questions/8509051/is-discard-bad-for-program-performance-in-opengl]()
It may be possible to disable anti-aliasing (if it isn't already) and get a speed-up.
[https://stackoverflow.com/questions/30261999/webgl-performance-issues-with-retina-macbook-pro]()
AHHHHHH I FIXED IT BY JUST CHANGING SOME FLAGS IN CHROME!!!
Switching between the openGL backend (slow) and metal backend (fast!!) seems to have solved the problem with zooming out!
[chrome://flags/]()
needs to be tested after we have pushed the new firefly 3.0 to main.
pinging @zhafen to remind myself he volunteered Tania's m1 as tribute. (we're not ready yet tho)
when you get a chance, can you:
Use tania's computer to go to ageller.github.io/Firefly and zoom out the FPS should drop precipitously as the particles are forced to overlap in fewer pixels.
If that happens, navigate to chrome://flags/
in the address bar. There's a search box, you should be able to type in ANGLE and then choose metal from the dropdown (see screenshot above).
Then visit ageller.github.io/Firefly again and see if it works better.
Confirmed that zooming out on an m1 results in a major FPS drop, and that following the above steps solves the issue.
When you zoom out on an m1 macbook framerate slows to ~4. When I tested this on my old intel macbook using the same data and same source JS files FPS never dipped below 44. Likewise, @ageller has tested on windows and not had this problem.
More testing on m1 machines would be helpful (and I have one in mind, thanks to @zhafen ). In this issue I will compile resources and attempts to address this performance issue.