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

[Michael Barton]

Maybe this will speed up some other modules too. Thanks very much.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Mon, 1 May 2006 18:28:59 +0100
> To: Hamish <hamish_nospam at yahoo.com>
> Cc: Michael Barton <michael.barton at asu.edu>, <werchowyna at epf.pl>,
> <grass-bugs at intevation.de>, <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] [bug #4356] (grass) d.m: d.rast.num fails when called
> from 'Add comand layer'
> 
> 
> 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>