[GRASS5] [bug #920] (grass) d.vect.line does not draw lines

[Eric G. Miller]

On Mon, Feb 18, 2002 at 02:10:29PM -0800, Eric G. Miller wrote:
> > I was actually talking about the part after the "rewind", i.e. once
> > the areas have been filled and the module draws the boundaries. At
> > least in the example I am working right now, this second part takes
> > longer than when I draw the boundaries with d.vect.
> 
> I'll look into it.  Need to make some changes for just drawing
> boundaries anyway (fillcolor=none).

I've looked into why d.vect.area is a bit slower to draw lines than
d.vect.  I'm not sure it can be made much faster.  There is a
significant difference between what d.vect is drawing and what
d.vect.area is drawing.  When d.vect draws lines relative to categories,
it is looking at the line category number.  So, d.vect only has to
look at each line once.  However, this method will likely not cause
all area boundaries to be drawn.  When d.vect.area draws lines, it is
drawing all of the boundaries for a given area.  This may result in
lines being drawn twice, but guarantees the interior boundaries, if
any, will always be drawn. 

The fill drawing code is still much slower than the line drawing code.
I played with a custom memory pool to minimize the malloc calls, but
it only shaved a second or less off of program execution time for a
dataset taking about 22 seconds to draw.  That's program execution
time, elapsed time was about 1.5 minutes.

Anyway, the only way I can think of to speed up the line drawing code
is to add a mechanism for tracking which lines have already been
drawn.  The most time efficient way, would probably be to read all
of the line numbers into a sorted array, and then mark them when
they have been drawn.  That'd add a bit to memory consumption, and
I'm not sure that the speed up would be too significant.

It might be possible to use left/right polygon numbers, so that lines
only have to be inspected once.  This method seems the most promising,
but there's a question about which line color should win for the
drawing color.  Right now, the last area boundary drawn wins (overwrites
previous color).

I'll try to get a fix in for drawing only fill or boundaries via the
"none" color argument in the next day or so.

-- 
Eric G. Miller <egm2 at jps.net>