[GRASS-dev] things to do before the 6.3.0 release
glynn at gclements.plus.com
Wed Dec 19 14:41:26 EST 2007
> but back to the d.vect rendering trials...
> > > 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.
> > I can't reproduce this.
> I get it consistently with 'd.vect streams width=1', any window size,
> did you try with my render_trial_width.sh script?
> > Does it occur with the PNG driver,
> No, only the XDRIVER with 'd.vect width=1'
> At the above URL dir compare
> 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
> > 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)
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 <glynn at gclements.plus.com>
More information about the grass-dev