[Xastir] New code testing

[Bryce Wolfson]

>> I still think it is the combination of slow laptop/map redraw/low zoom
>> level since a longer trip at higher zoom had no faults. My thoughts are
>> that the map needs redrawn, so a redraw is started. By the time the map
>> redraw is finished, I'm off the edge again. Due to screen aspect ratio
>> this happens more on north/south routes. This really only happens at
>> higher speeds, when I'm on streets at less than about 50mph, it doesn't
>> seem to happen.
> 
> Ok.  It's possible that the TrackMe code needs to initiate a map
> interrupt in this case, so that Xastir can try to keep up.  In that
> case you might not get a complete redraw before you get a map
> interrupt (depending on speed/zoom level/number & type of maps
> selected), so the maps drawn into memory won't even show up on the
> display.  Xastir might appear to be doing nothing, but in fact would
> be frantically drawing maps into a pixmap, then getting interrupted
> before you get to the copy-to-the-display stage, then starting the
> process all over again.  It might alleviate the segfaults you're
> seeing though, so it's probably a step in the right direction.
> 
> There's not a lot we can do about that except suggest running on a
> laptop capable of redrawing in the time allotted.  It seems to me
> that we should do the map draw interrupt in this case though, so
> that Xastir doesn't get bogged down trying to draw maps that you're
> already past, queuing up more maps to load as it goes.
> 
> Another thing we _could_ do is to copy the maps up to the display as
> each map is loaded into memory.  This would slow things down
> slightly overall, but would at least give you partial maps as you
> were going along.  Problem is, if we interrupt the map drawing when
> you get to the edge, you'd never get the weather alerts/ symbols/
> tracks drawn on top of the maps either, so you wouldn't even get to
> see where you were on the map.
> 
> Ideas anyone?

Keep a running average count of how long it takes to draw the map (perhaps
5-10 draws' worth), then at the beginning of a map draw take the GPS input
course and speed to project your position out the duration of a map draw,
and draw the map centered there. If course/speed change during the draw you
won't be at the center of the map by the time it's done drawing, but then
you apparently aren't at the center by the time it's done drawing using the
last-position-before-draw technique, either.

Regarding the map interrupt handling showing nothing vs. copying each map to
the display individually -- just copy the current aggregate image to the
display when an interrupt is received, only if the regular flush (on map
drawing completion) hasn't already occurred, _then_ abort and start the next
draw. This way you don't see the compositing happening, but if you run out
of time the flush should be a very quick operation by comparison to all the
drawing.

Both techniques get a lot of use in the real-time graphics world; the latter
can be used alone to improve things, but it works particularly well if you
do both -- try to project the correct position, then if the target goes off
the map before you're done drawing it (significant course and speed change,
or significant error in position projection) invoke the second technique of
bailing with a flush and reset.

Cheers.
-Bryce