Hi,
I am trying to fix d.save's recording of d.frame settings.
A partial fix is now in 6.3svn. (use FP not int for percent of frame
when recreating the d.frame command line)
There is still a possible off-by-one error though, found at the bottom
of the top row of frames.
e.g.
export GRASS_WIDTH=600
export GRASS_HEIGHT=900
d.mon x0
d.frame.split 6 # from wiki addons
d.frame -D
SCREEN STATUS:
time:15
cur_w:uno
FRAME: seis
time:14
d_win:600 900 300 600
FRAME: cinco
time:12
d_win:600 900 0 300
FRAME: cuatro
time:10
d_win:299 600 300 600
FRAME: tres
time:8
d_win:299 600 0 300
FRAME: dos
time:6
d_win:0 299 300 600
FRAME: uno
time:15
d_win:0 299 0 300
FRAME: full_screen
list:d.erase color=white
time:2
d_win:0 900 0 600
Shouldn't the 299s be 300s?
A similar thing is seen with the first column border if frames are
tiled horizontally. (d.frame.split -h flag)
I am trying to understand how the d_win=t,b,l,r window pad deals with
top and bottom.
GRASS_WIDTH and GRASS_HEIGHT are in number of pixels, xwininfo says
600x900, yet the d_win pad runs from 0-900 = 901 integers.
I could not find any clues in R_screen_bot(), R_screen_top()'s comments
in lib/raster/com_proto.c or in lib/raster/rastergraphicslib.dox beyond
"The upper left hand corner of the screen is the origin. The actual pixel
rows and columns which define the edge of the video surface are returned
with calls to <i>R_screen_left()</i>, <i>R_screen_rite(),
R_screen_bot(), and R_screen_top().</i>"
but is the origin pixel number 1,1; or 0,0 & the max size-1; or as it
seems now 0,0 & the max size-0. ?
or is it like the grass map region where the numbers are grid coordinates
not cell/pixel center coords??
confused,
Hamish
ps - d.save TODO:
check consistency of d.save's manufactured g.region calls per frame.
(missing from first frame?) so 'd.redraw -a' after zoom in one frame
correctly rezooms all other frames, without resetting the working frame.