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

[M Lennert]

On 17 Feb 02, at 12:58, Eric G. Miller wrote:

> I have no problem with that formulation.  I'd like to get some
> consensus on whether people feel one or several modules are appropriate.

I would prefer seperate modules.


> > Just for information: the drawing of the boundaries with d.vect.area
> > is much slower than when done through d.vect. Any idea why ?
> 
> Well, d.vect.area currently always does the fill, then rewinds the
> vector file to draw the boundaries.  It's the fill part that is
> slowest.  I think I have an unneeded line clipping routine in there,
> which G_plot_line() repeats (so, mine should come out).  The line
> clipping algorithm is pretty fast, so I'd bet it's mostly the
> fill part that is slowing things down (there are a lot of malloc
> and free calls, then a quicksort for the scan line conversion --
> the bigger the data set and the greater the number of islands,
> the slower it will be.   I don't think the rasterizer can get
> much faster, but I could look at reusing memory, which would
> probably help considerably.  A higher level interface to the
> plotting routines could also reduce the number of memory
> copies that occur -- could be down to zero copies.)
> 

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.

Moritz