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

[Glynn Clements]

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