So, I bought a new MacAir 16g recently and got back into d3 because of it Computer is basically brand new.
I’ve been building a choropleth and Observable keeps crashing and reloading due to ‘webpage was reloaded due to using too much memory’.
fill nested statement and there should be noticeable latency lag) when moving the mouse over the map.
ETA: the linked notebook reliably crashes around 1995 when the animation runs…
Not an Apple chip problem. The notebook just uses a ton of memory. Over here running through the animation 1 full time gets the memory use for that Safari tab up to 2.36 GB…
Maybe don’t make a completely new SVG for every frame?
Here’s a fork which re-uses the same SVG map for every frame:
But now it seems like the “tippy” tooltips aren’t updating as I would expect as the animation plays. You’ll have to debug that one yourself.
Also, changing the color of every county seems to be more computationally expensive than I would expect, slowing down the tooltips while the animation is going, so perhaps your code is doing more work than it needs to (or perhaps my expectations were off); I didn’t investigate too closely.
Edit: it seems like tooltips take a tremendous amount of memory; I don’t think the tippy library was intended for uses like putting thousands of tooltips around on a map and updating them in an animation. I would recommend trying to attach (the same) event listener to every county which renders a single tooltip when the mouse shows up and then destroys it when the mouse leaves.
Here’s a very odd behavior that @mbostock or someone else on the Observable team might want to look into. In my forked notebook above (at least in Safari 13.1 here), if I move the mouse around to see the tooltips with the cell editor for the map cell open, they open/close extremely quickly and follow the mouse around with no lag at all, but if I have the cell editor for the map cell closed, the tooltips become much laggier.
I can reproduce this in Safari as well. It seems that having any sufficiently long editor that is hidden in the notebook will cause this, regardless of its position. Although the origin of the style invalidation / repaint still seems to be tippy itself.