Hamish wrote:
> > 2) d.vect default render mode in 6.3 has been changed to "l" from "g".
> > For me (using xmons) this creates poorly rendered polylines and lots
> > of bad artifacts in the "whitespace padding" at the edges.
> >
> > see examples here:
> > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/
> >
> > (IIRC the min line width!=0 problem shown at the bottom of that page has
> > been corrected)
> >
> > Due to this I propose the default rendering should go back to "g" in the
> > 6.3.0 release branch.
Glynn:
> What's wrong with r, d and c?
see examples in above URL. (but wait 'til tomorrow; right now the server's down
due to electrical work in the building)
Are those up to date?
Also, which driver is used?
IIRC r and d's method of drawing polylines gives fuzzy results.
Does "r" look better without the +0.5 in local_plot_poly (display/d.vect/plot1.c)?
> g should only be used if none of the others can be made to work.
IIRC c is very close, AFAICT it is just the two white lines at the edges of the
map which are a problem.
For lines, c uses a R_move_abs() + R_cont_abs() pair for each segment,
while r, d and l use R_polyline_abs().
> To get rid of the problem with render=l drawing beyond the edge of the
> region, d.vect needs to set the raster clip window (R_set_window()) to
> match the region (D_setup() sets it to match the frame), but it needs
> to be set back afterwards (D_setup(0) should suffice).
Does that cure the incorrect polygon filling too? (1/2 way down in above URL)
I don't know.
Is 'l' the absolute favorite, or is it a case of choosing the best compromise
from several near equals? In the quality vs. time tradeoff we must have minimum
standards for both variables. I wouldn't mind the other methods if the above
issues could be fixed. Right now I think they fail the minimum quality test.
d, and l are equal, insofar as they should only differ with regard to
performance. Neither mechanism is fastest in all cases; d will be
faster if most of the data lies within the clip rectangle, while l
will be faster if most of the data is clipped away. For stream output
(PS, PDF, SVG), l may result in smaller files.
c is the slowest, but doesn't require raster-level clipping (which is
awkward, as there is currently no way to save/restore the clip
rectangle).
r is just a local implementation of d.
g is just wrong, as it uses libgis to perform rasterisation rather
than the driver, so it won't work with non-raster drivers, or even
with raster drivers which don't behave exactly as expected at a pixel
level (e.g. if they use anti-aliasing).
> Also:
>
> 1. d.vect uses the same rendering mode for both fills and strokes,
> which isn't necessarily desirable.
>
> 2. There should probably be two polyline clipping functions. One which
> fills the gap where a section has been clipped out, and one which
> doesn't.
In what cases would you want clipped to be anything other than a full mask?
displaying a solid boundary line when there is not one there is dangerous.
It depends if you want a clipped polygon boundary or the boundary of a
clipped polygon. I would assume that the former is more often useful,
but I wouldn't rule out the latter having uses.
--
Glynn Clements <glynn@gclements.plus.com>