[GRASS5] Re: [winGRASS] libG11 update

[Glynn Clements]

Mike Thomas wrote:

> > Crashes the monitor?
> 
> Hangs XDriver, lots of disk activity, then death of XDriver.
> 
> > That seems odd; all the monitor does is to fork() a subprocess which
> > calls system() for each command which was registered with
> > D_add_to_list(). It shouldn't make any difference if the commands are
> > d.vect or d.sites.
> 
> No, unless libG11 is getting confused about clipping for some commands and
> not others.

What I'm wondering is: why doesn't the command just crash XDRIVER in
the first place? The commands which are spawned to perform redraw
should be the same commands which were run previously (more or less;
e.g. d.sites qualifies the site files with G_fully_qualified_name(),
which converts e.g. "bugsites" to "bugsites at PERMANENT").

> > Does the output of d.save contain anything unusual?
> 
> "D.save" - great command - thanks for the tip!  There seems to be a problem
> after resize with the arguments to g.region".  Here is the output after
> starting the monitor, without displaying anything:

I was mainly interested in the case where something was actually
displayed, particularly a case which subsequently crashes. d.save
should list the commands which will be performed upon resize.

> Note the arguments to "g.region", blank in the second case.  Neither of
> "d.erase" or "g.region -d" fix this.  Is that normal?

Yes. The "g.region" line is the data from the "m_win" pad. This data
is set by D_check_map_window() (which is mainly called from
D_setup()), but "d.erase" deletes all of the pads.

> The other thing I notice is that the larger the monitor size, the slower the
> redraw.  Is that normal?

Yes, although the extent of this would depend upon what's be drawn. 
Erasing the window should be proportional to the window area, as
should raster layers. vector layers should be proportional to size
(width or height). site layers should take constant time. If there
isn't much being displayed, the erase will probably dominate.

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