[GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called from 'Add comand layer'

[Glynn Clements]

Hamish wrote:

> > > Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when
> > > called from 'Add comand layer'
> ..
> > >> Are you using d.m or gis.m?
> > > 
> > > gis.m doesn't use X monitors - d.rast.num will not under gis.m at
> > > all :).
> >
> > In fact, r.rast.num DOES work under gis.m Fortunately, it doesn't need
> > an xmonitor. As far as I know it is working fine with error checking
> > for raster resolution, etc. This is why I'm asking which GUI you are
> > having trouble with. Since this has changed pretty rapidly, I  should
> > also ask which build date are you working with.
> 
> If you haven't zoomed way in it used to tell you your numbers would be
> tiny and did you want to continue? [y]. Then it would get stuck like
> that in the output window.
> 
> d.rast.num just now updated in CVS not to use G_yes().
> If things are very bad, it tells you the problem and G_fatal_error()s.
> If things aren't so bad, it gives you a warning.
> If things are fine, it doesn't bother you at all.
> 
> gis.m already had a test to only run if given < 10,000 cells.
> 
> I notice rendering is fairly quick off screen, quite slow on screen.
> (e.g fliping to a different workspace speeds it up 100x)
> For me calling from gis.m seems to be 100x slow...

d.rast.num call R_flush() once per character. Ouch.

For the PNG driver, that call causes the image to be written out if it
has been modified (which, in this case, it will be; one more character
has been drawn).

For the X driver, it "clears" the window (i.e. fills it with the
background pixmap, onto which everything is drawn). I suspect that the
X server may defer the filling operation if the window isn't visible.

Fix: remove the R_flush() call from the bottom of draw_number(); it's
completely gratuitous.

Modules should only call that function once a sequence of drawing
operations have completed and no further operations will occur for an
indefinite period (e.g. until the user interacts via the mouse or
terminal).

Actually, any use of that call in a d.* module is either gratuitous,
or indicates an interactive module which need to be changed or
replaced as part of the GUI project.

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