Re: [matplotlib-devel] backend_wx update revision 1.9

[John H. <jdh...@ac...>]

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> I think this will also benefit the 'measurement' class. I
    Jeremy> saw that there were the beginnings of some code in
    Jeremy> backend_gtk (and this is a Matlab feature I've always
    Jeremy> loved), so I started to think about it... and quickly
    Jeremy> 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.

    Jeremy> I think it's wise to get the changes into CVS quite
    Jeremy> soon. It sounds as though you have most things sorted out,
    Jeremy> 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
  
    Jeremy> It would probably be polite to let the development list
    Jeremy> (and maybe even the users list) know when you've checked
    Jeremy> in potentially destabilising changes, but the refactoring
    Jeremy> sounds as though it will substantially simplify the
    Jeremy> backend implementations.

Will do.

    Jeremy> I've incorporated the current CVS verion of matplotlib
    Jeremy> into my throughput analysis application, and I'm already
    Jeremy> getting good feedback from colleagues on the improved
    Jeremy> charting. I can also confirm that I'm pretty impressed by
    Jeremy> the data clipping - I'm seeing very good performance with
    Jeremy> fairly large (~1MB x 3 axes data sets). I could probably
    Jeremy> supply a screenshot in a couple of weeks for the website,
    Jeremy> 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.

    Jeremy> I'll also try to write wx versions of some of the demos
    Jeremy> which I've marked as N/A (because they depend on GTK in
    Jeremy> some way - this will help people to get going with
    Jeremy> embedding in a wx App (and will give me something to post
    Jeremy> to the wxPyWiki at a later date).

    Jeremy> By the way, I've notice that Sourceforge takes a couple of
    Jeremy> days to update the mailing lists - rather longer than I
    Jeremy> expected.

Yep, sourceforge has been pretty flaky.

CVS update to follow.
JDH