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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
