[GRASS5] [bug #920] (grass) d.vect.line does not draw lines
fa1079 at qmul.ac.uk
Mon, 18 Feb 2002 10:44:01 +0000
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.