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

[Glynn Clements]

Hamish wrote:

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

Sorry, I don't understand. Can you clarify?

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

I can't reproduce this.

Does it occur with the PNG driver, or with a different X server?

> 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

Please specify the region, so that I can attempt to reproduce this.

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

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

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

I'll look into this later.

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

Yes, as it only works with the raster drivers (and may not work right
with the cairo driver if using anti-aliasing).

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

I would recommend using l as the default, as it should be the fastest.

[Actually, I also need to add code to remove 0-length segments. When
zooming in, there could be a lot of these.]

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

Some methods may have better performance with different types of data. 
E.g. g will be quicker if the data doesn't need to be clipped, while l
will be quicker at high zoom.

-- 
Glynn Clements <glynn at gclements.plus.com>