[GRASS5] PNG driver problem

[Glynn Clements]

David Piasecki wrote:

> Oh, I see now. It's not a separate command. It's simply an environment 
> variable.

Yes.

> Sounds like it's being written every time you perform an 
> operation like d.rast. Isn't that a little slow?

The extra time seems to be trivial compared to the rest of the
process.

> In some cases, I can 
> see it as beneficial. Now you can load layers and watch them appear one 
> at a time. However, now you have the overhead of writing out a PNG file 
> with every operation.

That version of the PNG driver can also write PPM files (by setting
GRASS_PNGFILE to a name which ends in ".ppm"). Also, you can set
GRASS_PNG_COMPRESSION to 0 to disable PNG compression (this may be
significant on systems with a slow CPU, e.g. handhelds, although the
difference seems to be negligible on a PC).

> Do you know if there will be a future command for 
> writing the PNG file so we can call it when we please?

That would involve extending the driver protocol, which I don't
particularly want to do without a compelling reason.

I wouldn't consider this to be a compelling reason unless there's
empirical evidence to show that writing the PNG/PPM file takes a
significant amount of time relative to the other parts of the process.

> As a temporary work around, what do you think of a GRASS script which 
> executes a sequence of commands before exiting? Would the PNG driver 
> consider that as a single operation and write once, or will it write 
> everything automatically?

The file is written when a client (d.* program) disconnects. The PNG
driver doesn't know anything about the bigger picture. Any support for
"batch processing" would have to be based upon heuristics, e.g. 
delaying the write until no client has connected for a given time
period, or only writing after every N operations.

-- 
Glynn Clements <glynn.clements at virgin.net>