Algorithms, data structures, tracks, speed, brainstorming

To be a bit more productive... many things could be made nicer and quicker and snappier with the right data structures. Just a quick brainstorm idea right from my bike saddle:

Locus could eg keep the main data for *all* tracks *always* in memory, not tucked away in some slowish sql database. Main data would be name, start & end point, covered area rectangle, color & style. I reckon thats no more than 100 bytes on average per track if stored efficiently. Even power users with a thousand or more tracks in their databases shouldnt run into memory troubles (100kB).

This "track index" must not be arranged in a simple list, but in some sort of spatial b-tree, a bit like http://en.wikipedia.org/wiki/R-tree . Then it will only take milliseconds to find out what is on-screen, no matter how many tracks you might have.

With a data structure like this "working in the background", I imagine Locus might do plenty cool things... and everything could be magnitudes faster than it is now.

For example, all tracks could always be "shown", their names fading in and out smoothly as I zoom in or out. And when I zoom in closer so that only a few tracks would be left on screen, Locus would start background tasks loading and displaying all their points dynamically. Everything happens independently from the main ui task and I could happily zoom and scroll around with 50fps even in the most extensive database.