[GRASS5] Re: [GRASSLIST:2702] Re: Grass 5.7 smart display

> The problem:
> showing on the monitor 156 maps takes a long time, even if you have
> a low resolution and your region is covers only one of the maps.

...

An alternative approach would be for d.rast to check whether the map
intersects the current region. If it doesn't, and the overlay (-o)
switch is used, then it can skip the drawing part (it still needs to
update the cell/cell_list/list pads, though).

That approach would be more generally useful than something which is
built into d.m. OTOH, it might still be too slow for 156 maps
(particularly on Cygwin, where simply spawning a program 156 times
would probably be too slow, even if the program itself did absolutely
nothing).

Another drawing aggravation:

If you change the window size (drag the corner) while several maps are
displayed, it will redraw all the maps on the list to completion before
noticing the window size has changed, then blank and redraw everything
again. Is it possible/practicable to check for a window resize between
drawing commands or even ~4 times per map?

This can be tedious when working over a tunneled X connection with
complicated maps..

Hamish

Hamish wrote:

Another drawing aggravation:

If you change the window size (drag the corner) while several maps are
displayed, it will redraw all the maps on the list to completion before
noticing the window size has changed, then blank and redraw everything
again.

This can be tedious when working over a tunneled X connection with
complicated maps..

So don't drag the window borders; use d.resize. Or configure your
window manager not to continuously emit resize requests during
dragging.

Is it possible/practicable to check for a window resize between
drawing commands or even ~4 times per map?

It may be possible, but it would be a great deal of work, and pretty
easy to get wrong.

The monitor has to spawn a child process to do run the commands, as
the main process has to keep running to service the requests which the
commands generate. The child process doesn't have anything to do with
X, and changing that (i.e. having both processes read the same X
connection) would be complex.

--
Glynn Clements <glynn.clements@virgin.net>