Well, nobody will mistake me for a graphics programmer...
I'm still having a bit of trouble with making d.area
work well (and jibe with d.vect).
The problems are:
1. d.area uses a different method than d.vect for map to
screen coordinate transformations. This results in
output that is skewed by a pixel here and there.
2. d.area does not clip polygons to the window, and there
doesn't appear to be any code in the GRASS libes that
can properly clip polygons that will be flood filled
(I've got the line clipping part...).
3. The "screenpoly" method for dealing with holes has at
least an exponential growth in time -- meaning large
complex data sets with lots of holes take a ridiculous
amount of time to draw. I also think the routines are
flawed for some border cases...
Number one can be handled by using the same drawing routines
as d.vect (G_line, G_polygon). But! Polygon clipping is
still an issue (#2). Also, the "screenpoly" code would have
to be rewritten to work on doubles rather than ints...
I haven't made any significant progress on a polygon clipper
that doesn't leave spurious edge lines (apparently the CELL,
and PNG drivers will do a 1 pixel line -- even those forward
and backwards lines are colinear -- but X handles this
scenario correctly). Note: this regards the fill portion,
not the border lines (if drawn).
My thought for improving the handling of holes, was to
dismember the polygons by splitting each by lines
cutting through each of the holes, and then reconstructing
several resultant polygons from the edges. The idea is
to reduce the amount of traversal through the vertex
arrays and reduce the number of operations necessary to
perform the task. Any X or Y line will do for the cutting,
and that part isn't so difficult, it's reconstruction that
I haven't quite figured out...
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).
Okay, that's way too long... 
--
Eric G. Miller <egm2@jps.net>