[GRASS-dev] Re: grass-dev Digest, Vol 23, Issue 59

[Michael Barton]

On Mar 14, 2008, at 2:40 AM, grass-dev-request at lists.osgeo.org wrote:

> Yann Chemin wrote:
>> When processing is done, they think their new map is going to be
>> displayed automatically (it is part of the  processing to display
>> output).
>
> maybe the refresh button could blink or get a different background  
> color
> when the display is known to be "out of date". Or from the other
> direction, be shaded (but still operational) if thought to be "up to
> date"?
>

Here's the reason for the 2 buttons.

The right button redisplays all maps. This means that underlying d.*  
commands are run, creating temporary PNM images of all maps to put  
into the display. This is what happens the first time any layer is  
rendered. With the right button, any and all changes to all maps show  
up in the display. But it takes a long time to display some really  
large raster maps. So this is where the left button comes in.

The left runs the underlying d.* commands ONLY for map layers that  
have been added or whose display options have changed (e.g., line  
color) since the last time the display was updated. Other layers are  
simply displayed from the existing temporary PNM images previously  
rendered by running d.* commands. So if you have a very large raster  
map already displayed and want to overlay it with a simple set of  
vector lines, the vector is rendered, but the raster is simply  
redisplayed from the image already rendered. There is a problem if  
you make a change to the underlying data of a file (e.g., change the  
color table). The GUI has no way of knowing that the underlying data  
of a layer has changed and doesn't know to rerender it. So you have  
to force it by clicking the right button. For changes the GUI does  
know about, the rendering button background potentially could change  
to indicate that it needs to be re-rendered.

Martin's been making some changes to the wxPython display system to  
help some of this (including optional automatic rendering whenever  
the options of a display layer is changed). Also, wxPython seems to  
display faster for a variety of rendering reasons, meaning that  
perhaps we can get rid of the fast rendering mode.

Michael