[GRASS-dev] python data object graphic output?

[Glynn Clements]

Michael Barton wrote:

> > That's all well and good, but how is the d.* command supposed to get
> > the data into the wxgui process if not through a file?
> 
> p = subprocess.Popen(['d.rast', 'map=myraster'], stdout=subprocess.PIPE)
> data = p.stdout

A file will typically be quicker. With a pipe, unless the reader reads
it all in one go, you get a context switch for every PIPE_BUF bytes.

Also, the PNG and cairo drivers support using an mmap()ed BMP file as
the frame buffer; if both sides map the file, you eliminate a copy.

But the best case for speed will be keeping everything in video
memory, i.e. using pixmaps. If you use the GPU for rendering, the
output ends up in video memory, so if you want it anywhere else, you
have to copy it from there (reading video memory is often signficantly
slower than writing to it, or than reading from system memory).

> >>> Better still, if you use cairo, it should be possible to have the
> >>> graphics hardware perform the compositing.
> >>>
> >>> The cairo driver has support for using an X Pixmap for its output  
> >>> (via
> >>> GRASS_CAIRO_DRAWABLE and GRASS_CAIRO_VISUAL). Not only would this
> >>> eliminate the need to copy data to/from disk (or even between
> >>> processses), but the d.* command can use the graphics hardware.
> >>
> >> This also sounds promising if it could be implemented from the Python
> >> GUI.
> >
> > That depends upon whether wx allows you to use a Pixmap as the source
> > for blending operations. If it's a wrapper around cairo, it should
> > work. The main issue is that it needs to keep the data within the X
> > server (which will keep it in video memory if possible).
> 
> Is this relevant for Windows? Workable for Mac without running x11?

I would assume that there are equivalents, but I don't know enough
about GDI/Quartz to say for sure. The main issue is determining how to
pass the surface handles between processes.

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