Hamish wrote: > Ha: > > > > > next problem- r,d inverse fill a small bay upon zoom in. > Gl: > > I can't reproduce the inversion with r/d and the PNG driver (using > > r/d with XDRIVER kills Cygwin's X server), but it might be sensitive > > to the region. Can you provide a region where this occurs? > > > region the same as in my render_trial_area_fill.sh, > g.region n=5528100 s=5526600 w=2053900 e=2055400 res=100
> ok, after a little d.zoom'ing I got it to invert, both XDRIVER and PNG > driver, both 'd' and 'r' methods. > g.region n=5527800 s=5526900 w=2054700 e=2055300 res=100 > export GRASS_WIDTH=600 > export GRASS_HEIGHT=338 > d.mon x1 > METHOD=d > d.vect Coast_isl_fj render=$METHOD Found it. For the PNG driver, it's caused by an integer overflow in the code which computes the intersection of a polygon edge with a scanline. I've changed the code to use FP arithmetic. For XDRIVER, it's caused by exceeding the 16-bit range, so the polygon passed to the X server will have the visible portion of the data embedded in a "spider's web" of garbage. So far as X's 16-bit coordinates are concerned, we have three main options: 1. Make d.vect use render=c only. But there might be other modules with similar issues. 2. Add clipping code to XDRIVER. 3. Replace the use of Xlib for rendering with the software rendering functions used by the PNG driver, so XDRIVER essentially becomes "PNGdriver in a window". Pros: no 16-bit limitation, anti-aliased FreeType fonts. Cons: likely to be slower, no joins on thick lines. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
