[GRASS-dev] Re: windows binaries

[Michael Barton]

So this kind of makes the changes I just made to d.vect.thematic obsolete?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam at yahoo.com>
> Date: Wed, 15 Nov 2006 13:39:26 +1300
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: <michael.barton at asu.edu>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: windows binaries
> 
> 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).
> 
> 
> ps - very cool feature.
> 
> how much more efficient is this vs. g.pnmcomp?
> 
> 
> Hamish