Algorithms, data structures, tracks, speed, brainstorming

joeloc shared this idea 10 years ago
Gathering feedback

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.

Replies (1)

photo
0

Obviously, "manual" showing and hiding of tracks would still be available. But the "automatic" view on the complete database without all this on/off/hide/show usability desaster that normally happens when you deal with a lot of tracks on the road might be simplified greatly.

Leave a Comment
 
Attach a file