[GRASS-dev] python data object graphic output?

[Glynn Clements]

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

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?

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

Well, drawing operations don't actually matter, as that is done within
the d.* command via cairo. The ability to perform blending internally
is the main issue.

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

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