[GRASS-dev] Re: windows binaries

[Glynn Clements]

Hamish 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).
> 
> ps - very cool feature.
> 
> how much more efficient is this vs. g.pnmcomp?

I'm not sure if there's any significant efficiency gain, but it's
probably simpler to use than manual compositing.

-- 
Glynn Clements <glynn at gclements.plus.com>