[GRASS-dev] python data object graphic output?

[Michael Barton]

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