[GRASS-dev] python data object graphic output?

[Michael Barton]

On Aug 12, 2008, at 10:24 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
>
> 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


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

Normally the 'drawing' includes rendering raster images. Transparency  
is set via alpha values. There is no problem with 'drawing' overlayed  
images in Python. We already do it with the scale and legend.

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

Michael

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