On Mar 14, 2008, at 2:40 AM, grass-dev-request@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