[GRASS5] Window Extents and region settings in X...

[Radim Blazek]

Eric G. Miller wrote:
> I noticed after the bit of work I've done on d.area, that I still have a
> small inconsistency with much of the rest of the display code.  Here's
> the scenario:
> 
> 1) User open's monitor
> 2) Monitor's dimensions aren't proportional to the current region
>    settings.
> 3) Display program set's up region setting translation after opening
>    driver.
> 4) Display program draws to monitor, but large portions in the Y or
>    X extents are unused.
> 
> This is especially disconcerting looking when a portion of a vector map
> abruptly cuts off, even though there's more vector data and window real
> estate available.  It's less disturbing with raster data, given its
> rectangularity already...
> 
> I noticed I wasn't catching this with d.area and portions of the vector
> will be drawn outside the "clipping area" because portions of the
> polygons lie within the "drawing area" and hence the whole polygon is
> returned, despite Vect_constraint_window() (which behaves correctly).
> 
> I wonder if it is desirable to keep this behavior, or to see if we can't
> have region settings (for display purposes) extended in whichever
> direction has the unused window real estate? I'm not sure that such a
> thing could be done in the driver/raster lib area in such a way that
> the display modules would all automatically utilize that adjusted
> window.  
> 
> P.S. For those of you following my d.area ramblings:  Other than the
> clipping thing, it seems to work well (albeit slow in extreme
> circumstances).  I did try to compare it to d.vect.cats and noticed that
> d.vect.cats seems to have a *HUGE MEMORY LEAK*.  So, d.vect.cats was
> unusable as a comparison (I had to end up killing it if I tried to draw
> all the possible categories for a certain large vector map).
> -- 

I think that region handling should be changed somehow. But that's task 
for g51. My suggestion (not thought over deeply yet) is to distinguish region
used by:
1) modules creating new data  
    which would use current region saved in WIND
and
2) monitor + display/query modules
    which would use region stored in memory of monitor.
    Each monitor would have it's own region.

Monitor region would always cover whole area of monitor.

New functions could be used for manipulating currend WIND, for example
display WIND on monitor (by rectangle), set WIND to region of selected
monitor, create WIND interactively on monitor, ...

Some problems with one shared region as is used now:
- user cannot rely on current state of monitor, if region was changed for
   a while, d.erase must be run even if region was reset to original size.
- it is impossible to run some script on data and at the same time
   explore maps on monitor (I forgot several times about it and I was very
   surprised why created data are incomplete)
- write access to database is always required even if user want only
   read/explore data.
- (more?)

I'm waiting for your criticism.

Radim


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'