[GRASS-dev] display window coordinates
hamish_b at yahoo.com
Thu Dec 20 03:40:26 EST 2007
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.
d.frame.split 6 # from wiki addons
d_win:600 900 300 600
d_win:600 900 0 300
d_win:299 600 300 600
d_win:299 600 0 300
d_win:0 299 300 600
d_win:0 299 0 300
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??
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.
More information about the grass-dev