[Xastir] New code testing

[Chris Bell]

> 
> On Wed, 23 Jul 2003, Curt Mills, WE7U wrote:
> 
> > Implemented in CVS.  Thanks for that idea.  It's very slick!
> >
> > It appears to be the operation that I would normally expect from
> > doing a zoom/pan in the middle of a map draw, and it's still very
> > fast.  We don't currently draw the weather alerts/symbols/tracks on
> > top of it if we get a map draw interrupt though.
> 
> I ran this new code mobile between work and a SAR meeting last
> night, then again on the way home.  I tried running it zoomed in too
> far to see what would happen, and the results were interesting.
> This is on a PP200 with 32MB RAM running ZipSlack 8.0, plus a few
> files from Slackware's X11 disks.
> 
> First:  I had no segfaults.  The hard drive remained very busy (LED
> was quite active).  Timing was set to read the GPS position every 2
> seconds.  While map drawing was going on, Xastir wasn't reading the
> GPS.  This resulted in straight track lines on the map where curved
> lines should have been present.  Once I zoomed out, normal operation
> happened immediately and I got curved lines again, except at the
> point where I flipped to the next map screen and again got a short
> straight segment, but it was mostly unnoticeable at reasonable zoom
> levels.
> 

Exact same results here.  Kinda cool to watch it draw my (delayed)
posit, with DR ghost (in a reasonable place, even!), then redraw.


> So...  What to do about it?
> 
> In a way it's operation that I expect, having Xastir ignore GPS
> input while it's busy doing other things.  I suspect with radio
> interfaces it's not such a problem, as they'll queue up and get
> serviced if/when Xastir isn't busy anymore.
> 

Nope, it is the main thread blocked, my track at home shows the posits
were not queued to the radio... it did not have them from the gps to
queue... 

> In another way, I wish I could do something about it, perhaps
> interleaving the drawing of maps with the servicing of incoming
> data?
> 
> Obviously the _right_ way to fix this is to decouple the map drawing
> and the interface code by putting each in separate threads or
> separate apps.  Xastir-2 will do this, so perhaps what we have now
> is good enough?

That was my thoughts... fix it right when we split the functionality,
and let users have a reasonably stable xastir-1.  If someone wants
cleaner tracks, zoom out, and/or load less maps for now.

> 
> I guess it depends on whether Xastir is still segfaulting for some
> people while in TrackMe mode and while using close-in zoom levels.
> 

I had TrackMe on, and was loading a ton of maps (shp, gnis, pdb, dos)
at zoom levels 1 and 2, no segfaults, just the gaps in processing.
With the recent code to flush gps data, it didn't even bog down
forever... stopping at a light was enough to catch up completely.
Changing zoom levels seemed to interrupt cleanly too (hitting
pgup/pgdn 5 times only caused one redraw).   

One little thought, maybe we could update the indicators on the status
line when the key is processed, even though it is pending, thus we
have visual confirmation of the action.

I am leaving for hawaii tomorrow for a week, with no net or RF access,
so will be quietly coding for a bit! :) 

Chris.