What nonsense! Gave up after reading this.
""" Where typical internet maps take 30+ seconds to load after each pan and zoom """
What typical maps are the talking about?
""" Where typical internet maps take 30+ seconds to load after each pan and zoom """
What typical maps are the talking about?
https://felt.com/map/San-Diego-Zoo-Virtual-Tour-LC3QHLPxR4yw...
I just loaded this big map on a pixel 4a and while it was laggy, it still responded and didn't crash
I tried it in Safari on my i9 late-2019 MBP and (after dismissing the warning message) I was barely able to move around.
It would likely be more performant if the map view was a single canvas and panning, segmentation and so on was done in a buffer and rendered to the canvas by blitting the pre-rendered sections, or something along those lines. Maybe even rendering the sections to WebGL textures and using a WebGL context for the canvas.
But something fun to notice with Felt is that the rendering library (LeafletJS) is using transform3d to do 2d translations (instead of just using translate), so you may wonder "why?" At least in Chrome (and it seems in Safari) if you use transform3d the browser is more likely to keep the div in its own layer. This will reduce a lot of the paint/compositing time, and make the frame rate dramatically better. Of course in this case the micro-optimizations are irrelevant in comparison to Felt's JS performance problems (which on my machine appears to be due to projecting 2000 points from lat/lng space to pixel space every frame.) Choosing to project points every frame is super confusing because the whole point of the translate/transform3d optimization is to avoid having to recalculate pixel space during the latency-sensitive pan interaction. Odd.