[GRASS-dev] Re: numeric-numpy-scipy for graphs?

Glynn Clements glynn at gclements.plus.com
Tue Apr 24 04:47:42 EDT 2007

Michael Barton wrote:

> > [BTW, on the subject of perfomance: I've extended the PNG driver to
> > support writing 32-bpp BMP files. More significantly, if you set
> > GRASS_PNG_MAPPED=TRUE, it will immediately write out the file, then
> > mmap() for use as its framebuffer, so it doesn't have to explicitly
> > write the file after each command.]
> Should we go ahead and set this in the rendering section of the TclTk and
> wxPython code?

Not unless you're planning on using the BMP format (which means
eliminating g.pnmcomp); it doesn't work with other formats.

[Essentially, the image format needs store the actual image data as
raw 32-bit pixels, which rules out both PNG and PPM/PGM. 32-bpp BMP is
just that: a 54-byte header followed by raw 32-bit pixels. TGA and PAM
might also be viable.]

On that subject, you really should look into eliminating g.pnmcomp. 
AFAICT, wxWidgets doesn't feature blending (although it should be able
to do compositing with binary mask), but you may be able to use e.g. 
PIL for that. Performing compositing internally would save on I/O when
enabling, disabling and re-ordering existing layers.

> Do we need to turn it off after each rendering?


BTW, I've added a simple BMP viewer in visualization/ximgview (not
compiled by default). The idea is that you can use e.g.:

	export GRASS_PNGFILE=map.bmp
	ximgview image=map.bmp &

to get vaguely XDRIVER-like behaviour using direct rendering.

d.* commands map the BMP file as their framebuffer (rather than
explicitly reading and writing it), and ximgview continually displays
its contents in a window.

This is primarily an experiment to see whether it would be sufficient
for people who prefer the CLI/XDRIVER model over a GUI, assuming that
7.x abandons stand-alone drivers altogether.

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list