[GRASS-dev] Re: grass-dev Digest, Vol 23, Issue 59
Michael Barton
michael.barton at asu.edu
Fri Mar 14 12:14:13 EDT 2008
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
More information about the grass-dev
mailing list