[Xastir] Re: recent cvs: Works good...

[Gerry Creager n5jxs]

Curt Mills wrote:
> On Mon, 20 Sep 2004, Gerry Creager N5JXS wrote:
> 
> 
>>1.  Apparently you've solved the problems associated with the latest
>>round of ImageMagick API fubars.  Works good now.  I've, once again, got
>>radar, Tiger, etc.
> 
> 
> Unintentional, I assure you.  Sure it wasn't IM putting out enough
> small bug-fix releases to get back on track themselves?

Blind hog/acorn theory?  Every once in a while they get enough 
bug-fixes/features put online to accidentally get them back to where 
their docs say they are?

>>2.  I saw no issue with excessive CPU utilization including when radar
>>or Tiger loads were ongoing.  That said,...
> 
> 
> Lots of profiling has happened recently, and lots of corresponding
> small code changes.

Understood.  I've been trying to follow the threads here, but work's 
been getting in the way.  I was merely confirming that it's no problem here.

>>3.  When radar or Tiger are loading, the program appears to steal a lot
>>of normal cycles and doesn't appear to service interrupts much at all.
> 
> 
> I believe what you are seeing is the ImageMagick loading routine
> taking up all the time.  I've noticed that before with your large
> radar image.  It's the main reason I don't tend to use that radar
> image anymore:  I didn't like my whole Linux box locking up every
> few minutes.

And I've recognized the potential for this, as well as the problems for 
UI-View folk.  I've started working on a 9-area CONUS plus AK plus HI 
mosaic for easier selection of what you want/where/when.  More when I 
get the last couple of hours to finish it off.

> Moving it to another thread would take a bit of work, roughly
> similar to how we do the GPS track downloading in a separate thread.
> We'd have to spawn off a thread, set a flag when we're done, then go
> back and update our weather alerts and symbols/tracks on top of
> that.  We'd also have to take care that we don't start another map
> redraw operation at the same time, but perhaps this could be an
> advantage as we could kill the current thread and restart another,
> making the map drawing more interruptible.
> 
> I suppose we could move ALL of the display area draws to another
> thread, in which case the main thread would be detached from any
> drawing.  We'd then just have to communicate with the map-draw
> thread enough to instigate a new draw, to interrupt the current
> draw, etc.  Might be fun trying to figure out what should go in each
> thread, and would be a lot of work to get there.

Just color my comments as brainstorming.... or maybe not even that high 
on the evolutionary scheme!

73, gerry
-- 
Gerry Creager -- gerry.creager at tamu.edu
Network Engineering -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020
FAX:  979.847.8578 Pager:  979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843