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

[Glynn Clements]

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