[GRASS5] help on d.area...

[Glynn Clements]

Eric G. Miller wrote:

> In the long run, it might be better to handle this type of
> operation in the display library, as it can probably be
> handled more efficiently through a scanbeam algorithm.
> However, this would require an extension to the drawing
> commands to do a multi-polygon draw.  Proper "window"
> clipping could also be handled more easily this way
> though GRASS definitely needs some general vector set
> operation routines (intersect/union/difference/...).
> 
> I noticed the GNOME related libarts/libgdkpixbuf have
> routines for scan conversions and drawing raster or
> vector data into an arbitrary buffer (not display
> dependent).  It's possibly useful to consider migrating
> to those libraries, as the output can be retargeted
> to a number of file formats or a display, and 
> there's support for things like complex line styles,
> alpha channels, pattern fills and splined text (don't
> know how good the wide character support is...).
> No reason to recreate the wheel, and the libes are
> in C, so they should mesh well with GRASS (though,
> I worry a bit about the overuse of the letter "g" and
> namespace clashes).

Unfortunately, this approach eliminates the possibility of device
independence (more or less; it isn't actually impossible to generate
600dpi rasters for printing, but it is extremely impractical).

I'm still inclined towards basing any future display architecture upon
PostScript. The only significant drawback would be the inability to
support translucency. The other problem, i.e. supporting CJK
languages, is definitely solvable; it's just a case of finding out how
typical CJK PostScript fonts are encoded.

In any case, even if we could render complex paths without
tessellation, there are plenty of other situations (i.e. other than
rendering) where tesselation would prove useful (e.g. area
calculations).

-- 
Glynn Clements <glynn.clements at virgin.net>