[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

Glynn Clements wrote:

> > > I would suggest adding a plot_polyline() function which uses either
> > > the render= setting or a separate option (e.g. lrender=). That allows
> > > people to compare the new implementation against the old one without
> > > having to keep an old version of d.vect around.
> > > 
> > 
> > Done. The patch is attached.
> 
> I intend to apply this, subject to a few changes:

I have committed the changes.

I have also added a D_polyline_cull() function, which discards lines
which are entirely outside of the clip region, but uses D_polyline()
for contiguous sections which are inside the region.

If the drivers were changed to support a clip rectangle, this would be
all that is required (you still want culling to avoid sending an
entire map when most of it will be discarded by clipping).

[Actually, the drivers do support a clip rectangle, but it's only used
for text.]

I haven't changed the clipping code to use polylines. It's actually
quite non-trivial, as it needs to construct new polylines containing
the endpoints which are generated by clipping. OTOH, culling doesn't
create new points, so it can just pass portions of the coordinate
arrays to the existing polyline functions.

I'm wondering whether it's worth the effort given that it's likely to
be discarded relatively soon. Clipping during rasterisation is likely
to be more efficient than geometric clipping.

BTW, this issue isn't limited to the PS driver (although it's likely
to be more noticeable there). XDRIVER also uses line joins with thick
polylines.

Also, this episode has highlighted another issue for the future: the
move and cont functions should be augmented with an "end" function, to
allow polylines to be constructed incrementally. There are cases where
having to collate the coordinates into an array is an (unnecessary)
inconvenience.

Without an end function, cont operations have to be rendered
immediately, which rules out handling a sequence of move/cont
operations as a single stroked path.

There should also be a way to generate closed loops (i.e. PostScript's
"closepath" operator). Simply making the last point the same as the
first point doesn't work in PostScript; you still get a pair of caps
rather than a join.

The idiom of bracketing primitives with begin/end (used by e.g. 
OpenGL) is probably the best approach. If you don't need a begin or
end for a particular primitive, you can make it a no-op, but it's a
good idea to make the application provide it just in case.

-- 
Glynn Clements <glynn at gclements.plus.com>