[GRASS-dev] display window coordinates

[Glynn Clements]

Hamish wrote:

> 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?

It's because:

1. d.frame at= has 0,0 at the bottom-left but the raster library and
   drivers have 0,0 at the top-left.

2. d.frame.split rounds 2/3 up to 66.6667

3. The code which converts the percentage to pixels truncates rather
than rounds.

The code which creates the window (D_new_window_percent() in
lib/display/window.c) subtracts the vertical values from 100 to get
values relative to the top-left, so the rounded-up values become
rounded-down values. E.g. for scr_t=0, scr_b=900, b=66.6667:

	int win_b = scr_t + (scr_b - scr_t) * (100. - b) / 100.0;

	= 900 * (100 - 66.6667) / 100.0
	= 900 * 33.3333 / 100.0
	= 29999.97 / 100.0
	= 299.9997
	= 299 (cast to "int").

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

900-0 = 900, not 901.

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

The top edge of the "screen" is at 0, the bottom edge is at 900. The
top pixel row has its top edge at 0 and its bottom edge at 1. The
bottom pixel row has its top edge at 899 and its bottom edge at 900.

If you're indexing the screen as an array of pixels, valid row indices
are 0 to 899 inclusive. The bottom value stored in the pad corresponds
to the Y coordinate of the bottom edge of the screen (900), not of the
top edge of the bottom row of pixels (899).

> or is it like the grass map region where the numbers are grid coordinates
> not cell/pixel center coords??

The numbers are coordinates, not indices.

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