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

[Hamish]

> > 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/index.html
> > 
> >  (IIRC the min line width!=0 problem shown at the bottom of that page
> >   has been corrected)

no, it is just that the default width=0 has been reenabled since a couple
of months ago (it was being reset to 1 internally) and the problem is only
seen with width=1.


> > 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?

I have now done some more tests.  Scripts for easy comparison attached.

The first is with spearfish's vector streams; adjusting d.vect width=:

PNG driver (results seem to be identical)
 http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_PNGdriver.png
 http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_PNGdriver.png

bonus problem:
I am not sure what's causing the frame breakage at the bottom of the "D"
frame. 90% of the time it looks ok in XDRIVER but not in PNG driver.
Happens in both sometimes. I would blame d.frame.quarter math but that only
runs once and the problem can come and go with d.redraw or d.out.file
format=png, so I begin to suspect d.frame, with some race condition which
makes the different speed of the PNG/X drivers trigger it or not??
Perhaps it is d.resize or d.save? Resizing to the same dimensions as the
monitor was opened with (d.resize w=800 h=900) causes it to happen.
?

back to d.vect rendering though,

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.



next problem- r,d inverse fill a small bay upon zoom in.
Also, "l" in XDRIVER fill is badly broken. "g" is correct in all cases.
  (the vector map for that section of coastline available upon request)
 http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_Xdriver.png
 http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png


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

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


and finally- "c" still has 1 pixel of white at the top and bottom of the
display:
 http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/


Glynn:
> 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. But the bugs in the others are probably not
so hard to fix.

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)


> 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).

Should we wait to know if "l" will be the default before adding that?

> Also:
> 
> 1. d.vect uses the same rendering mode for both fills and strokes,
> which isn't necessarily desirable.

Once we have finished this debugging and all methods are rendering
crisply we can pick winners, remove the render= option from d.vect,
and use the multiple best methods for each task directly in the code,
yes?

> 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.


Hamish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_trial_areafill.sh
Type: text/x-sh
Size: 903 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20071201/d620c844/render_trial_areafill-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_trial_width.sh
Type: text/x-sh
Size: 921 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20071201/d620c844/render_trial_width-0001.bin