Re: [matplotlib-devel] [Fwd: [wxPython-users] Re: using wxImage in C++ python extension]
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 + (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.sour
[matplotlib-devel] autoscaling
A while back, I put some effort into rendering an offset ticklabel, which allowed the user to do something like plot(linspace(10100, 10200, 100)) and the plot would look like a plot from 0 to 100, with a "+10100" rendered in a new label near the far end of the axis. This doesnt work quite as well as it used to, because the axes autoscaling is setting the plot range to something like the average plus and minus 6%. I have tried tracing the source of this change, but I can't find it. It might be buried in the _transforms extension code, and I've never been able to wrap my head around mpl's transforms. Does anyone know why autoscaling is defaulting to this +-6% range? Does it have to be this way? I'm trying to improve the scalar formatter (supporting engineering notation, cleaning up the code). Thanks, Darren - 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
Re: [matplotlib-devel] autoscaling
On 8/28/06, Darren Dale <[EMAIL PROTECTED]> wrote: > A while back, I put some effort into rendering an offset ticklabel, which > allowed the user to do something like > > plot(linspace(10100, 10200, 100)) > > and the plot would look like a plot from 0 to 100, with a "+10100" > rendered in a new label near the far end of the axis. This doesnt work quite > as well as it used to, because the axes autoscaling is setting the plot range > to something like the average plus and minus 6%. I have tried tracing the > source of this change, but I can't find it. It might be buried in the > _transforms extension code, and I've never been able to wrap my head around > mpl's transforms. > Does anyone know why autoscaling is defaulting to this +-6% range? I don't know anything about it what happened to the code, but I will say that +- 6% autoscaling is better than tight bounds for many kinds of plots. Like a scatter plot. It doesn't look good if some of your points are right on the axes, with their marker cut in half by the border. It's always bugged me with Matlab that there was no easy way to get slightly enlarged bounds on plots, so I'm glad to hear mpl has added something like that. I'm not sure it should be the default, or only option though. Some plots are better with tight bounds. --bb - 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
Re: [matplotlib-devel] autoscaling
Darren Dale wrote: > A while back, I put some effort into rendering an offset ticklabel, which > allowed the user to do something like > > plot(linspace(10100, 10200, 100)) > > and the plot would look like a plot from 0 to 100, with a "+10100" > rendered in a new label near the far end of the axis. This doesnt work quite > as well as it used to, because the axes autoscaling is setting the plot range > to something like the average plus and minus 6%. I have tried tracing the > source of this change, but I can't find it. It might be buried in the > _transforms extension code, and I've never been able to wrap my head around > mpl's transforms. > > Does anyone know why autoscaling is defaulting to this +-6% range? Does it > have to be this way? I'm trying to improve the scalar formatter (supporting > engineering notation, cleaning up the code). Yes. It is not a +-6% range in general, rather it is an adjustment that is made if the range is very small. The relevant method in Locator is: def nonsingular(self, vmin, vmax, expander=0.001, tiny=1e-6): if vmax < vmin: vmin, vmax = vmax, vmin if vmax - vmin <= max(abs(vmin), abs(vmax)) * tiny: if vmin==0.0: vmin -= 1 vmax += 1 else: vmin -= expander*abs(vmin) vmax += expander*abs(vmax) return vmin, vmax I know I did it this way for a reason, but I don't remember exactly what it was--whether it was because of problems with zooming when the zoom range gets too small (this was definitely a big problem), or because of problems with the rest of the locator code, or because it seemed to me to be roughly the desired behavior in most cases. Maybe it was all of the above. Certainly, something like this is needed--I think you will find that things go bad rapidly if vmin gets too close to vmax. I put in the "expander" and "tiny" kwargs in case of future need, but only expander is non-default (e.g., 0.05) in other parts of ticker.py, and neither kwarg is presently exposed to the user. That could be changed. Eric - 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
Re: [matplotlib-devel] autoscaling
Bill Baxter wrote: > > I don't know anything about it what happened to the code, but I will > say that +- 6% autoscaling is better than tight bounds for many kinds > of plots. Like a scatter plot. It doesn't look good if some of your > points are right on the axes, with their marker cut in half by the > border. It's always bugged me with Matlab that there was no easy way > to get slightly enlarged bounds on plots, so I'm glad to hear mpl has > added something like that. I'm not sure it should be the default, or > only option though. Some plots are better with tight bounds. Presently it kicks in only in the unusual case of a very small range, but it has also occurred to me that it would be nice to be able to tell the autoscaling to add a margin in any case. I just haven't gotten around to doing it. Eric - 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
Re: [matplotlib-devel] autoscaling
On 8/27/06, Eric Firing <[EMAIL PROTECTED]> wrote: > Bill Baxter wrote: > > > > > I don't know anything about it what happened to the code, but I will > > say that +- 6% autoscaling is better than tight bounds for many kinds > > of plots. Like a scatter plot. It doesn't look good if some of your > > points are right on the axes, with their marker cut in half by the > > border. It's always bugged me with Matlab that there was no easy way > > to get slightly enlarged bounds on plots, so I'm glad to hear mpl has > > added something like that. I'm not sure it should be the default, or > > only option though. Some plots are better with tight bounds. > > Presently it kicks in only in the unusual case of a very small range, > but it has also occurred to me that it would be nice to be able to tell > the autoscaling to add a margin in any case. I just haven't gotten > around to doing it. +1 for that. I've just recently been fixing my limits by hand in this way precisely to avoid the half-cut markers problem that Bill describes. Cheers, f - 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
