Hamish wrote: > but back to the d.vect rendering trials... > > H: > > > The first is with spearfish's vector streams; adjusting 'd.vect > > > width=' > .. > > > XDRIVER: (for r,d,l width=1 polylines render poorly, as seem in > > > original examples from quoted link at the top of this email. > > > > > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_Xdriver.png > > > > > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_Xdriver.png > > > > > > ok so that's the tiny gaps in lines for XDRIVER polylines with > > > width=1. > G: > > I can't reproduce this. > > I get it consistently with 'd.vect streams width=1', any window size, > XDRIVER. > > did you try with my render_trial_width.sh script? > http://article.gmane.org/gmane.comp.gis.grass.devel/23649 > > > Does it occur with the PNG driver, > > No, only the XDRIVER with 'd.vect width=1' > > At the above URL dir compare > dvect_render_0_PNGdriver.png > dvect_render_1_PNGdriver.png > dvect_render_0_Xdriver.png > dvect_render_1_Xdriver.png > > I just tested with latest svn, it's still there. > > > or with a different X server? > > You mean running GRASS over 'ssh -X' from another machine? > I haven't tried that yet.
Or with Xvfb (use xwd to capture the screen) or Xvnc. As I said, I can't reproduce this, either with my normal X server or with Xvfb/Xvnc. And while the behaviour of XDrawLine for zero-width lines is specified as being hardware dependent, the behaviour for non-zero widths is supposed to be the same on all platforms. So, I'm assuming that this is a bug in your X server. > > > next problem- in the PNG driver for all rendering methods but "g" the > > > boundaries and fills don't line up. It's obvious if you look with > > > xmag. > > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_C_and_all_but_G_xmag_PNGdriver.png > > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png > G: > > Okay, I think I know about this. Points and line vertices need to use > > floor(), while polygon vertices need round(). Oddly enough, "g" is using rounding: static int fastline(double x1,double y1,double x2,double y2) { move (ifloor(x1+0.5),ifloor(y1+0.5)); cont (ifloor(x2+0.5),ifloor(y2+0.5)); return 0; } [lib/gis/plot.c] This is incorrect, as the driver effectively introduces a half-pixel shift (an endpoint at <0,0> corresponds to the top-left pixel, whose centre is <0.5,0.5>). So if "g" is producing the correct results, there's an equal-but-opposite error elsewhere. > > > next problem- (xdriver) g & l methods don't line up: > > > d.vect Coast_isl type=area color=red fcolor=220:220:220 render=g > > > d.vect Coast_isl type=area color=blue fcolor=none render=l > > > d.grid -n 1000 > > > > > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/d_vect_gl_overlay.png > > > > render=l selects culling, not clipping. It simply discards segments > > which are entirely outside the clip window. It relies upon the > > raster-level clip window (R_set_window()) being set appropriately, > > which isn't the case for d.vect at present. > > No, I mean within the region frame. In d_vect_gl_overlay.png the blue > line is different than the red line, so it does not fully overlap/obscure > the red line underneath. Which method is more spatially accurate? No idea. The only way to determine that is if I have the actual data and the commands used to render it. > > > > g should only be used if none of the others can be made to work. > > > > > > currently 'g' is still the only one that works properly in all cases > > > for both XDRIVER and PNG driver. > .. > > > Do you have any objections to using "g" as the default for the 6.3.0 > > > release? (and leaving as-is [a work in progress] in 6.3.cvs) > > > > Yes, as it only works with the raster drivers (and may not work right > > with the cairo driver if using anti-aliasing). > > how about 'c' as the default for the 6.3.0 release then? > (if PNG driver boundary/fill line-up problem can be fixed) "c" is the least efficient. I'd rather add the raster-level clipping and use "l". I don't intend to just fudge it until it looks right; that's how it got into this state in the first place. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
