Hi,
I just threw up some new screenshots showing broken polygon fills with
d.vect render=l. What should not be filled, is partially filled.
Look near the end of the page:
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/
from those pics, and assuming we have to use the display library and not
the old libgis render functions, it appears that "c" would be a nicer
pick than "l", if the two bands of white at the edges could be corrected.
Hamish
Hamish wrote:
I just threw up some new screenshots showing broken polygon fills with
d.vect render=l. What should not be filled, is partially filled.Look near the end of the page:
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/
from those pics, and assuming we have to use the display library and
not the old libgis render functions, it appears that "c" would be a
nicer pick than "l", if the two bands of white at the edges could be
corrected.
Another d.vect issue, in 6.3cvs the new D_line_width() forces the
minimum line width to 1, which creates ugly jagged line output vs a line
width of 0.
This patch makes it nice again:
RCS file: /home/grass/grassrepository/grass6/lib/display/draw2.c,v
retrieving revision 1.11
diff -u -r1.11 draw2.c
--- lib/display/draw2.c 8 Apr 2007 18:03:29 -0000 1.11
+++ lib/display/draw2.c 13 Jun 2007 09:58:05 -0000
@@ -847,8 +847,8 @@
int w = round(d);
double m;
- if (w < 1)
- w = 1;
+ if (w < 0)
+ w = 0;
R_line_width(w);
screenshots can be found at the URL at top of this email.
(Spf roads buffered 5m)
The screenshots also show some north-south shift error in some lines
using different rendering methods.
see also previous talk about line width=0,1 WRT v.digit and tcl minimum
width inputs:
Glynn wrote:
http://thread.gmane.org/gmane.comp.gis.grass.user/17458/focus=18731
Odd. I initially suspected that Tk may have a different interpretation
of "width" compared to X etc. However, having traced the Tk drawing
routines with GDB, I can confirm that the width entered in the
Settings dialog is passed directly[1] into the X GC.
then:
http://thread.gmane.org/gmane.comp.gis.grass.devel/20444/focus=20503
finally:
(11 May 2007)
Hamish:
n.b. the smallest D_line_width is 0, not 1. width=1 still looks a
little lumpy. (experiment with d.vect)
Maciej:
> Are you absolutely sure? Glynn says it's really 1:
> http://grass.itc.it/pipermail/grass-dev/2007-February/029336.html
Hamish:
Well I was sure, but not so much anymore! I could have sworn I could
see the difference in the past. Can't seem to now.
(by then R_line_width() had changed to D_line_width())
.. something is funny here. As seen in the screenshots linked above
there is a real difference, at least in the XDRIVER output.
Hamish
Hamish wrote:
> I just threw up some new screenshots showing broken polygon fills with
> d.vect render=l. What should not be filled, is partially filled.
>
> Look near the end of the page:
>
> http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/
>
> from those pics, and assuming we have to use the display library and
> not the old libgis render functions, it appears that "c" would be a
> nicer pick than "l", if the two bands of white at the edges could be
> corrected.Another d.vect issue, in 6.3cvs the new D_line_width() forces the
minimum line width to 1, which creates ugly jagged line output vs a line
width of 0.This patch makes it nice again:
Index: lib/display/draw2.c
RCS file: /home/grass/grassrepository/grass6/lib/display/draw2.c,v
retrieving revision 1.11
diff -u -r1.11 draw2.c
--- lib/display/draw2.c 8 Apr 2007 18:03:29 -0000 1.11
+++ lib/display/draw2.c 13 Jun 2007 09:58:05 -0000
@@ -847,8 +847,8 @@
int w = round(d);
double m;- if (w < 1)
- w = 1;
+ if (w < 0)
+ w = 0;R_line_width(w);
I suggest:
if (w < 0)
w = 0;
R_line_width(w);
if (w < 1)
w = 1;
Otherwise, D_line_width(0) will set a clip/cull margin of zero.
.. something is funny here. As seen in the screenshots linked above
there is a real difference, at least in the XDRIVER output.
Notes:
1. X doesn't specify exactly which pixels are plotted when drawing
lines. In practice, the definition may be "whichever pixels the video
chip's line-drawing hardware decides to plot". IOW, the result can
vary depending upon your video hardware.
2. There can be significant differences in the behaviour of
XDrawLine() etc depending on whether the line width is zero.
Essentially, a line width of 1 results in a "thick" line while 0
results in a "thin" line. Thick lines are treated as defining a filled
area centred on the line, e.g. if a polyline intersects itself, the
intersection will only be drawn once (which is significant if using
e.g. the GXxor function).
--
Glynn Clements <glynn@gclements.plus.com>