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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
