matplotlib-devel Mailing List for matplotlib

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: 2006年8月18日 16:48:08 +0000 (UTC)
From: Andrew Murray <and...@st...>
Reply-To: wxP...@li...
To: wxp...@li...
References: <200...@uc...> 
<44E...@al...> <200...@uc...> 
<44E...@no...> <44E...@al...> 
<44E...@no...>
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: wxP...@li...
For additional commands, e-mail: wxP...@li...
-- 
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
Chr...@no...

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
 Edin> Hi all, Please John, take some time before SciPy conf to
 Edin> answer at least some of this questions, because the SoC
 Edin> deadline (21st August) is *very* near.
Alas, I am already here and have been a little out of email contact
while traveling. Sorry for the delay.
 Edin> 1) I'm having some problems regarding FT2Font. The problem
 Edin> is when I instantiate FT2Font like: font =3D FT2Font(filename)
 Edin> and when I call it's method font.set_text("Some text"), and
 Edin> afterwards, font.draw_glyphs_to_bitmap(), the latter simply
 Edin> deletes every glyph that was drawn before it, and just
 Edin> paints in the internal image buffer the text that was passed
 Edin> on last invocation of set_text (or load_char).
This is a feature, not a bug :-) You can clear the image buffer if
you want with the clear method, as we do in the mathtexy code
 for fontface in self.fonts.values():
 fontface.clear()
 Edin> This is a pain, because draw_glyphs_to_bitmap implements the
 Edin> layout (with kerning etc.), but if one wants to paint
 Edin> several words in different x,y positions in the same image
 Edin> buffer, he has to do the layout for every character in every
 Edin> word manually via draw_glyph_to_bitmap(x, y, glyph) (like
 Edin> you did with the BaKoMa fonts in mathtext).
 Edin> Why hasn't draw_glyphs_to_bitmap been implemented so that it
 Edin> takes x, y as arguments (draw_glyphs_to_bitmap(x, y)) and
 Edin> leaves the image buffer intact (as does
 Edin> draw_glyph_to_bitmap)?
You can add optional x and y args to draw_glyphs_to_bitmap if you need
them. Just make sure any changes you make pass
examples/backend_driver.py and unit/memleak_hawaii3.py
 Edin> 2) As I have said before, I have started the complete
 Edin> rewrite of mathtext (the parsing stuff etc.). I have
 Edin> completely removed the dependency on pyparsing (please don't
 Edin> yell at me :), and I was wondering about how much of TeX
OK, I won't yell. Quietly scold maybe :-)
I am skeptical of your -- or anyone's except Robert's -- ability to
parse TeX mathematical expressions w/o a true recursive descent
parser. I took a look at your code but w/o any running examples I
could not test it. From reading it, I do not think it will be able to
handle the deeply recursive structures that are currently supported by
the existing, working parser. Can you handle recursively nested
super/sub scripts? Can it parse this
 tex =3D r'$\cal{R}\prod_{i=3D\alpha_{i+1}}^\infty a_i\rm{sin}(2 \pi f x=
_i)$'
If so, I apologize for my skepticism, but my working assumption is you
will need a proper parser to parse tex and string methods aren't going
to get you there. What I really need to see before even considering a
system that replaces the working system is an argument about why it
needs to be replaced, and more importantly, code that can do
everything the old code can do, such as render the mathtext_demo.py
example? =20
 Edin> should mathtext support. I'm not talking about support for
 Edin> \frac, \above, \choose (which I plan to add one by one)
 Edin> etc., but about more general things - macros (\def etc.). I
\above, \frac and \sqrt yes, \def no. Others I'm not sure about. =20
 Edin> was thinking of just simulating them, at least to a
 Edin> tolerable extent, via notion of an enviroment. Example: \rm
 Edin> in plain TeX sets the current font to roman (until the end
 Edin> of the current scope - 'till it hits "}"). Implementation:
 Edin> At render time, when the parser hits "\rm", it does the
 Edin> folowing: env["facetype"] =3D "rm", where env is the
 Edin> environment in the current scope.
Can we use classes here rather than dictionaries? Syntactically, I
prefer env.facetype =3D "rm" to the dictionary syntax.
 Edin> Also, I am planing to create a separate class for every new
 Edin> layout item that gets implemented. Example:
 Edin> sub/superscripted item (nucleus_sub^sup) gets translated to
 Edin> an instance of class Scripted that has the attributes
 Edin> nucleus, superscript and subscript.
 Edin> 3) I was thinking of focusing on just the Agg backend for
 Edin> now (that is till' the deadline). Is this OK? 4) I think
 Edin> that we should move the job of math_parse_s_ft2font,
 Edin> math_parse_s_ft2font_svg, and math_parse_s_ps etc. to the
 Edin> corresponding backends, and that some general function like:
 Edin> math_parse_s(x, y, s, prop, angle) should be implemented
 Edin> directly in mathtext.py (perhaps even without the "angle"
 Edin> parameter) so that it returns a list of the following type:
 Edin> [(x1, y1, s1, prop1, angle1), ... , (xn, yn, sn, propn,
 Edin> anglen)]
I can't address these questions until I understand why you are trying
to rewrite, rather than extend or fix, the existing code. The agg and
the postscript backends work with the existing frameowork. As far as
I can see, you could fix the layout engine in the existing framework
and not have to think too much about backends, with the exception that
you need a basic backend line drawing API for things like the
horizontal line in \frac.
 Edin> 5) What would be the consequences of distributing a GPL font
 Edin> (FreeFont) with matplotlib. I mean, it's not that using a
 Edin> GPL font in some non-GPL app could be a breach of the
 Edin> GPL. Is there any interest in this?
Don't underestimate the zealousness of GPL advocates. I have been
informed by the FSF that merely providing a backend that does=20
import qt
in a backend that is optionally included at runtime by a user who may
be using a GPL version of QT or may be using a commercially licensed
version of qt (we can't know which) makes the entire code base of mpl
GPL'd. This claim was provided w/o argument and I frankly find it
ludicrous. Robert can probably tell you the IANAL response to
including GPL'd fonts but I'm not too interested in distributing them.
We can always point the user to a web site and they can download them
from.
 Edin> The new mathtext.py is attached. Please do not try it at
 Edin> home ;) because nothing visible yet works.
OK.
JDH

Charlie Moad wrote:
> I'll paste the block of interest to save
> you a little digging.
> 
> bbox = self.replot
> w, h = int(bbox.width()), int(bbox.height())
> l, t = bbox.ll().x().get(), bbox.ur().y().get()
> reg = self.copy_from_bbox(bbox)
So this is one copy.
> stringBuffer = reg.to_string()
Is this another? or does to_string not copy?
> qImage = qt.QImage(stringBuffer, w, h, 32, None, 0,
> qt.QImage.IgnoreEndian)
Here we have difference from wx -- AFAICT, a wx.Image doesn't do rgba32, 
it does RGB24, with a separate 8bit alpha channel. if to_string copies 
anyway, then that wouldn't make much difference.
But do we really need alpha here anyway?
> self.pixmap.convertFromImage(qImage, qt.QPixmap.Color)
> p.drawPixmap(qt.QPoint(l, self.renderer.height-t), self.pixmap)
And this looks like wx.
I wish I had more time to work on this, but I'm in a crunch that I'll be 
in for while....
-Chris
-- 
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
Chr...@no...

Darren Dale wrote:
> I think all the high rollers are at SciPy 2006.
Oh right. This is the third year in a row that I have ALMOST gone 
myself. Maybe next year.
But what's the deal? Aren't they all hooked up to wifi and checking 
email constantly?
-Chris
-- 
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
Chr...@no...

On 8/17/06, Christopher Barker <Chr...@no...> wrote:
> Hi all,
>
> I seem to be talking to myself here, but if someone (including myself)
> wants to pick this up in the future, it'll be good to have it in the
> archives.
>
> Christopher Barker wrote:
> >> There is also the
> >> wx.Image.SetDataBuffer method, which will have the wxImage use the
> >> buffer passed in without making a copy, but if the buffer doesn't
> >> live as long as the image does it will likely cause a crash.
> >
> > This would probably be the easiest way to get top performance at the
> > moment. If we can make the Agg data a buffer, and somehow do the
> > reference counting right so it doesn't get deleted while the wxImage is
> > still around (that may not be hard -- the wxImage has to be converted to
> > a wxBitmap to be drawn anyway)
>
> I've been suing this for another use, and Robin just added an improved
> version of new wx.Image factory function I wrote for just this purpose:
>
> def ImageFromBuffer(width, height, dataBuffer, alphaBuffer=None):
> """
> Creates a `wx.Image` from the data in dataBuffer. The dataBuffer
> parameter must be a Python object that implements the buffer
> interface, such as a string, array, etc. The dataBuffer object is
> expected to contain a series of RGB bytes and be width*height*3
> bytes long. A buffer object can optionally be supplied for the
> image's alpha channel data, and it is expected to be width*height
> bytes long.
>
> A reference to the data and alpha buffer objects are kept with the
> wx.Image, so that they won't get deleted until after the wx.Image
> is deleted. However please be aware that it is not guaranteed that
> an object won't move its memory buffer to a new location when it
> needs to resize its contents. If that happens then the wx.Image
> will end up referring to an invalid memory location and could cause
> the application to crash. Therefore care should be taken to not
> manipulate the objects used for the data and alpha buffers in a
> way that would cause them to change size.
> """
> image = wx.EmptyImage(width, height)
> image.SetDataBuffer(dataBuffer)
> if alphaBuffer is not None:
> image.SetAlphaBuffer(alphaBuffer)
> image._buffer = dataBuffer
> image._alpha = alphaBuffer
> return image
>
> Does the aggDrawer already implement a Python buffer object? If so,
> using this would be easy. If not, then it probably should, unless we go
> straight to the numpy array protocol.
I haven't had time to thoroughly absorb all your post. From skimming
it looks like we could do a similar approach as the qtagg blitting.
If you look at the else clause in the FigureCanvasQTAgg.paintEvent
method, you'll see we added a to_string method to the BufferRegion
object. Using this string buffer we create a QImage and blit it. It
includes the alpha channel. I'll paste the block of interest to save
you a little digging.
 bbox = self.replot
 w, h = int(bbox.width()), int(bbox.height())
 l, t = bbox.ll().x().get(), bbox.ur().y().get()
 reg = self.copy_from_bbox(bbox)
 stringBuffer = reg.to_string()
 qImage = qt.QImage(stringBuffer, w, h, 32, None, 0,
qt.QImage.IgnoreEndian)
 self.pixmap.convertFromImage(qImage, qt.QPixmap.Color)
 p.drawPixmap(qt.QPoint(l, self.renderer.height-t), self.pixmap)
- Charlie

On Thursday 17 August 2006 7:19 pm, Christopher Barker wrote:
> I seem to be talking to myself here
I think all the high rollers are at SciPy 2006.