[GRASS-dev] things to do before the 6.3.0 release

[Glynn Clements]

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 at gclements.plus.com>