[Xastir] Re: Interesting APRSdos map!

[Curt Mills]

On Sat, 6 Mar 2004, Henk de Groot wrote:

> Yes, I guess it could be done in two steps, first draw in memory on an
> extended -360/+360 +90/-90 grid and then display the final bitmap centered
> as the user would like it. The -180 to -360 area should then be
> superimposed on the 180 to 0 memory area (bitwise OR) and +180 to + 360 on
> the -180 to 0 memory area; that's easy enough with a bitmap.
>
> To show it centered where the user wants it would be just cutting the
> memory of final bitmap image at the points were the new left and right
> border should be and "glue" the +180 to the -180 edges. I don't know the
> performance pealty for this, but I guess that would bearable when all
> drawing takes place in memory and only the final image is superimposed and
> displayed.

Since we do copies anyway from pixmap->pixmap->pixmap->Display while
we're drawing, doing four smaller-size copies instead of one larger
copy wouldn't be really any performance penalty.  An exception to
this is if you were to be using a larger pixmap than we do now.
Right now they're all screen-size, and I see no reason to make them
bigger.  We could do what you suggest algorithmically instead of
with a larger pixmap.


> All the other code can just go ahead using vectors and polygons on the
> fixed positioned memory image and would not be burdened by what is finally
> displayed. The only complication is that you only want to render what is in
> view to save memory and performance. Since with an area from -360 to +360
> you always have two separated areas to draw (which happen to overlap in the
> end) and when centered on the -180/+180 longitude that would mean four
> separated areas in the memory image should be rendered.
>
> Okay, this is just thinking out loud. I did not give it a lot of thought,
> so maybe it is a dumb idea afterall. I still have a gut feeling that map
> rendering and display logic should be two separate things and that
> rendering should not be burdened by how it is finally presented to the
> user. Different projections are of course also an issue for which this
> solution will not work, you don't want a flat bitmap to make a polar view
> map for example...

Unfortunately you got me interested in thinking about it a bit with
your recent messages.  I don't have much time for new projects right
now, which is why I used the word "unfortunately".  ;-)  Of course
there's no reason _I_ have to do it...  There are quite a few other
developers, but I would definitely like to see it incorporated into
the code at some point.

Drawing on the extended area like you suggest would increase the
memory requirements for at least the first pixmap quite a bit.  The
same thing could be done via algorithms instead of bitmaps, just
having the low-level code wrap at the edges instead of truncating.
We would need to look at all of the drawing routines (and there are
quite a few of them now) and rewrite them with this in mind.  Since
there's so much work involved in doing this, I want to make sure
that it's worth the effort and that we'd be implementing it in the
correct fashion the first time.

Perhaps we could reorganize all of the drawing routines to use the
draw point, draw vector, and draw polygon routines right from the
start, so that we could later modify those few routines to correct
everything?  The code could use some reorganizing, so we'd be
killing two birds with one stone, and making it easier to do code
maintenance in the future.  I wrote some low-level point/vector draw
functions recently:  Perhaps those could be tweaked to automatically
handle the "edges" of the earth, so that the upper-level code
wouldn't have to worry about it.  Needs more thought.

The "measure" routine doesn't handle edges either.  It assumes a
flat piece of paper and computes the distance on that paper.  If two
points where just across an "edge" from another, "measure" would
calculate a very long distance for it.  I wrote that for SAR work,
where the size of the search area is typically very small.  Where I
do SAR we're not near an edge.  No chance of falling off the earth!

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"