Timeline responsiveness could be improved by pre-calculating changes

[martindholmes]

For every timeline point, the current code just iterates through all the features to see which should be shown or hidden, but of course we could pre-build a map of timeline points to features visible at that point, on page load, and then we can just look up the features to handle. If we do this on page load, and delay any timeline start process until it's complete, the timeline point code will be much smoother and have less impact on anything else which is happening in the GUI at the same time.

[martindholmes]

This pre-calculation is going to be a bit complicated because it has to incorporate taxonomy membership too, since users can change taxonomies at any time. So what needs to happen is that, for every timeline point, we need a map of all features that should be showing, but we need to be able to look them up by taxonomy. Because we need to check those against the set of features that was previously showing, we also need access to a stashed version of those features. Because we know that whether or not the user has switched taxonomies between the timeline points, any currently-showing features which are not part of the set which needs to be shown now must be hidden, we should actually be able to use Sets for this. The first thing we do is construct a simple Set of the features which should be shown based on the currently-active taxonomy and the features whose timelines overlap the current point. Then we check every member of the Set of features which was previously shown (that Set was stashed in a variable), and where the previous Set member is not a member of the current Set, hide it; then we show all members of the current Set, and then assign the current Set to the previousSet variable.

That's my initial plan, at least.

[martindholmes]

Working on this in branch issue-50-optimize-timeline. It's not clear that it will definitely solve the problem, so the work needs to stay in a branch until it's thoroughly tested.