Hamish wrote:
> > > > > 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
>
> but I only see it after running d.resize*:
> d.resize w=1200 h=1350
>
> the initial 400x300 window doesn't show it. (a sixth of 800x900)
> export GRASS_WIDTH=800
> export GRASS_HEIGHT=900
> d.mon x1
> # split display into six frames (from wiki addons)
> d.frame.quarter -6
>
>
> [*] d.resize: I've given up on bloaty dumbed-down GNOME and never liked
> the look of KDE, so I've gone back to using the fluxbox WM. There xmons
> can not be resized by dragging on a corner for some reason. I've never
> noticed this for any other X app, which makes me wonder if it is xmon
> specific after all. We discussed this some time ago:
> http://thread.gmane.org/gmane.comp.gis.grass.devel/8709/
> but this is another matter, and rather low priority.
>
>
> 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
Okay, I can reproduce it with that region and monitor size.
I'll look into it later.
> Another thing I now notice, which I can replicate with 'd' and 'r', is
> area fill is not happening for some islands. (Both PNG and XDRIVER)
> See attached. If 'd.vect type=area' all the islands on the left are
> missing. (but the ones in the middle are ok)
>
> g.region n=5541800 s=5513200 w=2035900 e=2072600 res=100
>
> export GRASS_WIDTH=600
> export GRASS_HEIGHT=338
>
> d.mon x1
> METHOD=d
> d.vect Coast_isl_fj render=$METHOD
The island in question is entirely outside of the region. This might
result in it being discarded before it gets to the rendering stage.
FWIW, I don't get the outline either.
> Ha:
> > > how about 'c' as the default for the 6.3.0 release then?
> > > (if PNG driver boundary/fill line-up problem can be fixed)
> Gl:
> > It looks like it's going to have to be "c". r, d and l all risk
> > passing out-of-range coordinates to XDRIVER, which will produce
> > complete garbage and may even kill the X server.
>
> ouch.
>
> I take it there is some reason the Xdriver can't contain some sort of
> bounds checking {if(x > xmax) x=xmax;}, I assume you would have already
> done that if it were possible... :)
It would need to perform geometric clipping. The segment can't simply
be discarded if one endpoint is out of range, and the x and y
coordinates can't be adjusted separately, as that would change the
angle.
I suppose that it would be possible to perform both culling and
clipping: first cull to the region, then clip to the limits of X's
coordinate system. This would be more efficient than clipping
everything to the region.
But the clipping would only need to be done for XDRIVER. As the
display library doesn't know which driver is being used, the code
would need to be added to XDRIVER itself. I'm not sure if it's really
worth the trouble, given that it's never been a problem for anything
other than d.vect with render=r/d/l. I'd rather just make d.vect use
render=c and be done with it.
For 7.x, overflow isn't an issue for either PostScript or cairo. OTOH,
we do need to think about how to handle simplification. E.g. we don't
want to generate huge PS/PDF/SVG files containing entire maps where
all but a small region will be clipped away, or to render boundaries
where the average segment is 1/100th of a device pixel.
Personally, I think that this kind of processing belongs in d.vect,
particularly the second issue. If you're generating PS/PDF/SVG files,
there's no way of knowing the ultimate device resolution, and it isn't
really the display architecture's job to perform vector-level
simplification.
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
