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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev