[GRASS-dev] Re: windows binaries

[Hamish]

Glynn Clements wrote:
> > Here's an idea: if direct rendering had an option to initialise the
> > framebuffer from an image file (or PPM/PGM pair), building up an
> > image by having multiple d.* commands render on top of each other
> > would work, in the same way that it does with persistent drivers.
> 
> I've added this feature to libpngdriver (so it affects both the
> standalone PNG driver and direct rendering).
> 
> If you set GRASS_PNG_READ to TRUE, it will read $GRASS_PNGFILE (either
> a PNG file or PPM/PGM pair) into the framebuffer at startup. This
> allows you to build up a rendered image by overlaying multiple d.*
> commands.
> 
> The file(s) must exist, and match the various PNG driver environment
> variables in all respects, otherwise a fatal error occurs. So long as
> the file was generated from a previous invocation with the same
> settings, there shouldn't be any problems.
> 
> Note that GRASS_PNG_READ mustn't be set for the first command, as the
> file(s) won't exist yet.
> 
> This feature is useful primarily for scripts (e.g. d.vect.thematic)
> which run multiple d.* commands to generate a final result. It should
> be simpler than managing and compositing the various layers manually. 
> It also works with PNG files as well as PPM/PGM pairs (we don't have a
> PNG version of g.pnmcomp).


could you add a description of it to lib/init/variables.html ?
 (internal use section)

There are now so many arcane GRASS shell variables controlling different
parts of the system, we should try very hard to keep them all documented.


thanks,
Hamish