[GRASS-dev] discussion: replacing ps.map

[Glynn Clements]

Trevor Wiens wrote:

> > My first preference is to enhance the graphics architecture so that
> > d.* commands can generate PostScript. But this requires some
> > fundamental architectural changes which can't happen in the 6.x
> > timeframe.
> 
> This brings up a point worth thinking about. There has been much
> discussion about the current image rendering in GRASS, which right now,
> generates an image and displays it. People have discussed direct
> drawing of vectors, etc. Now as Glynn has pointed out in the past, ps
> isn't designed for fast rendering, but if display ps files were kept to
> low enough resolutions, the speed of display would still be pretty fast
> and then there would be no need for two library options.

PostScript data doen't have a "resolution".

The biggest performance hit for using PostScript is that there
typically isn't a "fast path" for single-pixel lines.

The general PostScript line-drawing algorithm is quite complex, as it
has to allow for dash patterns, join styles (including mitre control)
and caps. The algorithm essentially converts each dash to an area,
then fills it.

> The quality of
> the basic output could be adjusted and other tools could be used to
> convert the eps or ps files to images as needed. Now this may not work,
> but some time tests might be worth doing to see how much of a penalty
> would be paid for taking this approach. 

To conduct such a test, generate a PostScript representation of a
vector map using ps.map, then compare the time taken to render it to
an image with "gs" against using d.vect with direct rendering.

It might be worth trying with a line width of zero; PostScript allows
this as a special case:

	A line width of 0 is acceptable, and is interpreted as the
	thinnest line that can be rendered at device resolution - 1
	device pixel wide. However, some devices cannot reproduce
	1-pixel lines, and on high-resolution devices, they are nearly
	invisible. Since the results of rendering such "zero-width"
	lines are device-dependent, their use is not recommended.

It's conceivable that some drivers might implement a fast path for
zero-width solid lines.

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