[GRASS-dev] display window coordinates

Hamish 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.


export GRASS_WIDTH=600
export GRASS_HEIGHT=900
d.mon x0
d.frame.split 6   # from wiki addons

d.frame -D
FRAME: seis
       d_win:600 900 300 600
FRAME: cinco
       d_win:600 900 0 300
FRAME: cuatro
       d_win:299 600 300 600
FRAME: tres
       d_win:299 600 0 300
FRAME: dos
       d_win:0 299 300 600
FRAME: uno
       d_win:0 299 0 300
FRAME: full_screen
        list:d.erase color=white
       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 mailing list