[GRASS5] Re: [bug #3613] (grass) g.region vect=frame: bottom of the vector not visible

[Hamish]

> I cannot get d.frame to work for me. Eg.:
> 
> GRASS 6.1.cvs (caves_utm33):~ > d.frame at=0,0,50,50
> <at=0,0,50,50> invalid request


Usage:
 d.frame [-cepslD] [frame=name] [at=bottom,top,left,right]

(full usage wasn't given in man pages or GUI until recently)


try

d.frame at=0,50,0,50



d.split did this:

#  split it: left (win1) and right (win2)
        d.frame -e
        d.frame -c frame=win1  at=0,100,0,49
        d.frame -c frame=win2  at=0,100,50,100
or
#  split it: top (win1) and bottom (win2)
        d.frame -e
        d.frame -c frame=win1  at=50,100,0,100
        d.frame -c frame=win2  at=0,49,0,100


100-50 != 49-0, so the left or bottom panel is slightly smaller than its
partner, allowing the one frame to be slightly zoomed vs the other.

The split should be 0->49.5 and 50.5->100; now fixed in CVS. (bug #3628)


these two commands should give some hints as to this bug (#3613):
d.frame -D
d.info -r

Using xmag on the new version shows that things are better, but still
maybe off a little bit, more obvious as you strech the window bigger.

In fact doing:
v.in.region test_box
export GRASS_WIDTH=1000
export GRASS_HEIGHT=800
d.mon x1
d.split cmd1="d.vect test_box" cmd2="d.vect test_box"

and then using the mouse to drag the left/right side of the window to
resize & redraw highlights the bug -> after 3-5 resizings the right
panel grows at the expense of the left one. (Vertical resizing doesn't
make a difference in this view=vert case)

And when using d.split view=horiz and resizing in the vertical you
see the same thing happen too (but not by resizing in the horizontal).

Again I'd blame a truncation cast vs. correct rounding in the C code.



Hamish