display window coordinates

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

display window coordinates

hamish-2
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.
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: display window coordinates

hamish-2
> Hamish wrote:
> > I am trying to fix d.save's recording of d.frame settings.
...
> > There is still a possible off-by-one error though, found at the
> > bottom of the top row of frames.
Glynn:
> 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.

lib/display/window.c updated in 6.3SVN to round. thanks for the hint.
Now the frames all draw (and d.redraw) well AFAICT.


> > 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 meant the integer set [0,900].

Hamish:
> > 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." ...
Glynn:
> 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.
...
> > 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.

thanks, that makes sense.


Hamish



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

osgeo transition: script woes

hamish-2
In reply to this post by Glynn Clements
Hi,

in case this wasn't noticed yet, two little problems since the OSgeo
svn migration:

- i18n stats table is broken
  http://grass.ibiblio.org/devel/i18n.php#statistics

- weekly snapshot is still pulling from (dormant) CVS.
  http://grass.ibiblio.org/grass63/source/snapshot/


thanks,
Hamish



      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: osgeo transition: script woes

Markus Neteler
Hamish, all,

On Dec 21, 2007 12:39 PM, Hamish <[hidden email]> wrote:
> Hi,
>
> in case this wasn't noticed yet, two little problems since the OSgeo
> svn migration:

it was noticed but so much work and so little help...
I am currently offline and cannot fix that from here. But it
is easy to fix:


> - i18n stats table is broken
>  http://grass.ibiblio.org/devel/i18n.php#statistics

just get GRASS-Web-SVN (see trac.osgeo.org/grass/) and fix
the paths in
trunk/devel/i18n_stats.inc

to
http://download.osgeo.org/grass/grass63/binary/linux/snapshot/

> - weekly snapshot is still pulling from (dormant) CVS.
>  http://grass.ibiblio.org/grass63/source/snapshot/

Just fix the download links to
http://download.osgeo.org/grass/grass63/binary/linux/snapshot/
http://download.osgeo.org/grass/grass63/source/snapshot/

etc. Still the 6.2 cronjobs have to added (will do when back).

In general, we have make grass.osgeo.org to become the main
web site. This requires some more work which we have to do
in January.

Please fix above,
thanks
Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: osgeo transition: script woes

Markus Neteler
In reply to this post by hamish-2
On Dec 21, 2007 12:39 PM, Hamish <[hidden email]> wrote:
> Hi,
>
> in case this wasn't noticed yet, two little problems since the OSgeo
> svn migration:
>
> - i18n stats table is broken
>   http://grass.ibiblio.org/devel/i18n.php#statistics

fixed.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev