[GRASS-dev] d.vect render= and corrupted vector display

[Glynn Clements]

Maciej Sieczka wrote:

> I have tried different render methods with a vector box which fits the
> region perfectly. For each render method the vector box is displayed
> wrong on the X mointor. Details:
> 
> in spearfish:
> 
> $ g.region rast=elevation.10m -a
> $ v.in.region output=frame type=line
> $ d.mon x0
> 
> #1
> $ d.vect frame rander=g
> (right egde of the vector box invisible)
> 
> #2
> $ d.erase; d.vect frame render=r
> (right egde of the vector box invisible)
> 
> #3
> $ d.erase; d.vect frame render=d
> (right egde of the vector box invisible)
> 
> #4
> $ d.erase; d.vect frame render=c
> (nothing is visible)
> 
> #5
> $ d.erase; d.vect frame render=c
> (nothing is visible)
> 
> Then I repeated tests with width=2 and greater.
> 
> For cases 1-3 the right edge became visible, but the right and left
> edges were thinner than top and bottom.
> 
> For case 4, no matter what width nothing is visible.
> 
> For case 5, width > 1 makes the right edge visible, but the other 3 are
>  never displayed.

I've changed the clipping/culling code to handle this particular case
(i.e. use <= 0 rather than < 0), so #4 and #5 now match the other
three.

Beyond that, the main issue is that the code which sets up the
coordinate mapping (D_setup/D_do_conversions) maps the current region
to the current frame *exactly*, without any margin. This is arguably
the right thing, even if the net result isn't always ideal (and the
result of v.in.region is the worst possible case).

This doesn't allow for thick lines, where the path itself (i.e. the
centre-line) might lie just outside the region but the "stroke" can
still be visible. It also doesn't allow for the fact that the tiniest
rounding error might push the path outside.

Note that the clipping/culling code doesn't make any allowance for the
line width. It can't; it doesn't know the line width (R_line_width()
does directly to the driver; the display library doesn't get to see
it).

I should probably add an option to set a "margin", i.e. the difference
between the clip window used for the actual rendering and the clip
window used for geometric clipping and culling.

There's also the issue that the actual line may vary by +/- half a
pixel from the "correct" position. That's an inevitable fact of
rasterisation; the driver can't fill half of a pixel. If the path lies
exactly along an edge of the "screen" (window/image), the line will
end up either just on-screen or just off-screen.

FWIW, if you try this with the PS driver and width=1 (which translates
to one point, not one device pixel), and render the PostScript at a
high resolution, you'll note that it really does draw half of each of
the two vertical lines (adding "[10] 0 setdash 1 setlinecap" makes it
more clear).

-- 
Glynn Clements <glynn at gclements.plus.com>