[Xastir-Dev] some ideas for map speedups

[Curt Mills, WE7U]

On Mon, 7 Jul 2003, Alan Crosswell wrote:

> I jotted down some ideas for improving vector map performance on the train this AM:
>
> - Insinuate an intermediate vector data structure layer between the map-specific
> file reading functions and the map display functions (instead of directly
> invoking X drawing functions).  This then canonicalizes all vector maps to a
> single Xastir internal data structure which captures the attributes we care about.
>
> - Cache these vectors into memory up to a certain configurable memory limit.
>
> - Sort the memory vector list by display_level:  Major features that display at
> level 8192 are earlier in the list, those that display at level 1 are last in
> the list.  When rendering, it becomes really easy to decide when to stop -- and
> the map draws in order of feature prominence.
>
> - Cache 25%(?) more than the current viewport to support quick panning and
> zooming out.
>
> - Use available idle cycles in a low-priority thread to continue filling out
> around the edges of the viewport and drilling down to more detailed vectors
> (remembering the above sorting).
>
> - Get really smart and use dead reckoning prediction when tracking a moving
> station to determine what to render/cache next.
>
> - Potentially allow writing this cache out to disk for faster reuse and to
> support "swapping."

Hmmm.  Somebody make this guy a developer!

Oh wait, we already did...

Just a few comments:  I like most of the above, but keep Xastir-2 in
mind.  You might not want to put a lot of energy into most of the
above until we get the basic database back-end structure up and
running, else you might end up doing a bunch of work for nothing, or
at least might redirect optimization efforts elsewhere at that
point.  The rules are going to change.

If we were to continue along the Xastir-1 development chain, making
the above ideas very useful, I think that the dead-reckoning thing
should probably be last on your list or dropped altogether.  I think
the amount of effort put into it compared to what is gained is a
poor ratio.

Thinking along the Xastir-2 lines again, if were were to put the
vector data into a spatially-enabled database, we could then do SQL
queries to get just the data we need for each zoom level, and could
do background queries to fill out in-memory queues like you're
talking about in order to speed things up for zooming/panning.

If were were to either convert all of the map data to Xastir
coordinate system, or convert Xastir to use lat/longs, so that all
of the program and map data had a consistent coordinate system, that
would speed us up as well.  Same for datums:  We could convert all
map data to the correct datum as we imported it into the database.

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"