[GRASS-dev] python data object graphic output?

[Michael Barton]

On Aug 12, 2008, at 3:22 PM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>> With the revamp of the GRASS graphic driver output system, I'm
>> wondering about the feasibility of having a driver that creates a
>> Python data object rather than a disk file.
>
> Can you elaborate?
>
> Specifically, how is the data supposed to be transferred from the d.*
> command to the GUI?

A couple new modules seem promising in this regard:

BitmapFromBuffer:

"Two new wx.Bitmap factory functions allow you to create a wx.Bitmap  
directly from a data buffer. The the buffer can be any Python object  
that implements the buffer interface, or is convertable to a buffer,  
such as a string or an array. The new functions are:

wx.BitmapFromBuffer(width, height, dataBuffer, alphaBuffer=None):  
Creates the bitmap from a buffer of RGB bytes, optionally with a  
separate buffer of alpha bytes.

wx.BitmapFromBufferRGBA(width, height, dataBuffer): Creates the bitmap  
from a buffer containing RGBA bytes. "

ImageFromStream:

"At long last there is finally a way to load any supported image type
directly from any Python file-like object, such as a memory buffer
using StringIO."

Both seem to allow python data objects, rather than files to be the  
source of bitmaps for display

>
>
>> While this might not
>> create noticeable speed improvements in rendering displays in a  
>> Python
>> canvas, it could considerably simplify coding for overlaying and
>> rendering multiple geospatial data layers--especially if we can do  
>> the
>> compositing and rendering with Python tools rather than g.pnmcomp.
>
> Even with the modules writing image files, the compositing step really
> should be performed within Python, rather than using an external
> process (g.pnmcomp). This would mean that enabling or disabling layers
> or changing the translucency level would happen instantly.
>
> AFAICT, wx itself doesn't have code for this, although there may be
> third-party libraries which do. GDK has compositing code which can use
> SSE; it may be worth taking that (if someone hasn't already).

It seems like the new GraphicContext does this:

"The new advanced 2D drawing API is implemented via the  
wx.GraphicsContext and wx.GraphicsPath classes. They wrap GDI+ on  
Windows, Cairo on wxGTK and CoreGraphics on OS X. They allow path- 
based drawing with alpha-blending and anti-aliasing, and use a  
floating point cooridnate system.
When viewing this sample pay attention to how the rounded edges are  
smoothed with anti-aliased drawing, and how the shapes on the lower  
half of the window are partially transparent, allowing you to see what  
was drawn before."


>
>
> 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.

Michael

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