I think this will also benefit the 'measurement' class. I
> saw that there were the beginnings of some code in
> backend_gtk (and this is a Matlab feature I've always
> loved), so I started to think about it... and quickly
> decided against it!
Yes, I've used this in a GTK app which controlled an EMG machine. The
new transform architecture is pretty clean, in my biased opinion
<wink> and should make these kinds of things easier. The xaxis and
yaxis instances store two Transform instances 1) relative->display and
2) data->display. Since transforms know their inverse, it is easy to
get from display->data. You can do it like:
itransx = axes.xaxis.transData.inverse() # display->data transform
itransx = axes.yaxis.transData.inverse()
x, y = event.x, event.y # mouse location in display coords
x = itransx.positions(x) # data coords
y = itransy.positions(y)
Much cleaner than before! Although I should finish the log stuff
before I get too proud of myself.
> I think it's wise to get the changes into CVS quite
> soon. It sounds as though you have most things sorted out,
> and I can make changes fairly quickly.
Will do, I've finished changing over the GTK backend and PS backend.
You can diff the GTK backend against the earlier version to see where
most of the changes are required. Also, see the API changes listed at
the header of axes.py.
In a nutshell
- Init all Artists with a dpi instance variable, a Bound2D instance
variable. In the derived Figure class, this will need to be done
for the figurePatch and AxisText instances you create.
- remove any gc clip code you have in the figure or AxisText class
- replace any transformations you do in AxisText draw with the
transx and transy attribute calls
- make sure you get the get_window_extent just right by activating
the bbox_artist calls in Axis._draw. Run an example with if 0:
replaced by if 1: with the gtk backend to see what I mean
- Note that all of the viewlim and transform variables are passed
by reference in axes.py, so all transforms are updated
automagically with a change to the viewlim with no functional
calls. See transforms.py. Likewise for DPI. It is now a mutable
instance variable so you should update it with
self.dpi.set(newval)
rather than
self.dpi = DPI(newval) # this would break the reference
self.dpi = newval # this is illegal, dpi is a DPI instance
- lose all the set_size stuff and call axes.resize() in response to
figure resize events, *after updating the figure bbox*. Since
the axes has a ref to the figure now, you don't need to pass any
information to the axes after you have updated the box. Note as
above, in the figure class do
self.bbox.set_bounds(l,b,w,h) # update existing instance
rather than
self.bbox = Bound2D(l,b,w,h) # breaks the references
> It would probably be polite to let the development list
> (and maybe even the users list) know when you've checked
> in potentially destabilising changes, but the refactoring
> sounds as though it will substantially simplify the
> backend implementations.
Will do.
> I've incorporated the current CVS verion of matplotlib
> into my throughput analysis application, and I'm already
> getting good feedback from colleagues on the improved
> charting. I can also confirm that I'm pretty impressed by
> the data clipping - I'm seeing very good performance with
> fairly large (~1MB x 3 axes data sets). I could probably
> supply a screenshot in a couple of weeks for the website,
> if you're interested.
I'd love a screenshot. As for 3x1MB, you can probably go
substantially beyond that if you have a decent PC. I routinely plot
15MB files with good performance. 100MB gets a bit pokey on my
machine. Numeric is really amazingly fast. But in future versions,
I'd like to support memory mapped files to support really large data
sets.
> I'll also try to write wx versions of some of the demos
> which I've marked as N/A (because they depend on GTK in
> some way - this will help people to get going with
> embedding in a wx App (and will give me something to post
> to the wxPyWiki at a later date).
> By the way, I've notice that Sourceforge takes a couple of
> days to update the mailing lists - rather longer than I
> expected.
Yep, sourceforge has been pretty flaky.
CVS update to follow.
JDH