Chris,
Thanks for the cross-post. I'm not sure this approach will help
speed up the wxAgg accelerator, but I'll put it on the list of things
to look into. The problem I foresee is that the Agg renderer's RGBA
data has to be converted to RGB before a wxImage can be created by
convert_agg2image().
Ken
On Aug 18, 2006, at 6:14 PM, Christopher Barker wrote:
> As a probably final installment in the thread about optimizing the wx
> back-end, here is a post from the wxPython list, in which someone
> posted
> SWIG code for making a PyBuffer from his data set, then using it to
> create a wx.Image without copying. A similar approach could be used
> for
> the wxAgg back-end.
>
> -Chris
>
> -------- Original Message --------
> Subject: [wxPython-users] Re: using wxImage in C++ python extension
> Date: Fri, 18 Aug 2006 16:48:08 +0000 (UTC)
> From: Andrew Murray <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> Hi all :)
>
> I've followed the combined advice of Robin and Christopher in using
> a python
> buffer object to instance a wx.Image in the python wrapper layer. It
> all seems
> to be working - and I don't think there are any 'data copies' going
> on ;)
>
> To keep my underlying C++ python-free, I introduced the buffer (and
> creation of
> the wx.Image) via my .i Swig file. In case anyone who is reading is
> keen trying
> to solve a similar problem, I've included the code that I added to
> my .i
> file in
> order to implement the change below. (I'd appreciate any comments
> regarding
> errors or shortcomings that anyone spots in my implementation.)
>
> Sorry I didn't reply to the thread earlier. A combination of being
> tied
> up with
> more boring work, moving house and background research into using
> python
> buffers
> with Swig means that I've only just got this far.
>
> One remaining question I have is: Does the call to wx.EmptyImage
> that I make
> cause any memory to be allocated? I see from Robin's recent post
> that in my
> case this call is now redundant (as I will soon be using
> ImageFromBuffer) - but
> I'm curious to know the answer anyway ;)
>
> Thanks for all the help. The more I use wxPython the more I like
> it...
>
> Andrew ;)
>
>
> /* the RawImage C++ class that we are wrapping offers a method that
> returns a pointer to an internal 'unsigned char' buffer of display
> data. To make the python class generated by SWIG a bit more
> friendly to the rest of our wxPython code we instruct SWIG to make
> two modifications during the wrapping process. First we add a
> method to the C++ class that will return a version of the internal
> display buffer wrapped up as a 'python buffer object' (performing
> this in the C++ wrapper class keeps the wrapped C++ python-
> free)...
> */
> %extend RawImage {
> PyObject* RawImage::getDisplayBuffer(void) {
> // return a new 'python buffer object' that intialised using
> // the memory address and length of our display buffer...
> void* pvBufferData = (void*)self->pcGetDisplayData();
> int iBufferSize = self->getDisplayBufferSize();
> return PyBuffer_FromMemory(pvBufferData, iBufferSize);
> }
> }
> /* ... we also add a method to the python wrapper class that will use
> the buffer offered by our new C++ method to create a wx.Image
> (neither of these methods actually copies the image data)...
> */
> %extend RawImage {
> %pythoncode %{
> def getImage(self):
> # create an unintialised wx.Image of the correct size...
> wximage = wx.EmptyImage(self.getWidth(), self.getHeight(),
> clear=False)
> # then define the data content of the image...
> wximage.SetDataBuffer(self.getDisplayBuffer())
> return wximage
> %}
> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: wxPython-users-
> [EMAIL PROTECTED]
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
