[GRASS5] XDRIVER and redraw - suggestion

[Bob Covill]

Markus Neteler wrote:

> Hi Glynn,
> 
> On Wed, Jan 30, 2002 at 05:31:26PM +0000, Glynn Clements wrote:
> 
>>Markus Neteler wrote:
>>
>>
>>>while on the one hand the redraw function of XDRIVER is nice,
>>>it can become rather annoying with large maps (say, 500MB-1GB
>>>remote sensing data).
>>>
>>>What about following suggestion: the XDRIVER reads the environmental
>>>variable
>>>XDRIVER_MAX_NREDRAW
>>>which defines the maximal number of maps kept in the monitor
>>>list. If not defined, no limitation, if defined, the user
>>>can specify the maximum numbers of maps to be redrawn. Inthis
>>>case the XDRIVER forgets about the older drawn maps.
>>>
>>>It would be nice to have this optional variable.
>>>
>>Note that XDRIVER doesn't know anything about "maps"; it just has a
>>list of commands which it runs whenever the monitor is resized. 
>>Determining which commands constitute a "map" and which don't isn't
>>straightforward; "d.rast" isn't the only command which draws maps.
>>
> 
> yes, agreed.
>  
> 
>>Ultimately the XDRIVER resize kludge is just a quick workaround to
>>compensate for the absence of an interactive UI. Realistically, the
>>monitors should just be dumb graphic "devices"; state management
>>belongs elsewhere (the fact that, currently, there isn't a suitable
>>"elsewhere" doesn't doesn't change that).
>>
> 
> also agreed.
>  
> 
>>If the command list is getting too long, use "d.erase".
>>
> 
> Mhh, that's not unknown to me - but still inconvenient to be
> the only way to solve the problem. The proposed variable would
> change nothing for the standard behaviour of the monitor but
> allows in (our?) particular case to improve the situation unless
> a new, great system is written.
> 
> Probably you can think again about the idea? :-)
> 
> Thanks,
> 
>  Markus
> 


Hi Glynn & Markus,

Sorry about wading into this one a bit late, but I have been away for 
the last week.

A couple of questions that I have for the auto-redraw (which is a great 
feature) are:

(i) Is it possible check for duplicate draw commands and only execute 
the last one. For example I often draw rectified air photos repetitively 
on top of each other to examine changes. If I then resize the monitor it 
then re-executes each of the draw commands, even though they are identical.

(ii) The solution to all of this might simply be some sort of cancel 
command (d.cancel) that kills the current draw execution. In Markus's 
example of drawing a large image, the draw could be cancelled saving a 
bit of time. Currently if I want to kill a draw command I have to get 
the procees ID and execute kill. This may be over-complicated but worth 
considering??

-- 
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill at tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498