On Aug 13, 2008, at 12:47 AM, Glynn Clements wrote:
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.
OK. These are very good points. We'll try to work with the new
architecture as it develops.
Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
