matplotlib-devel Mailing List for matplotlib

John Hunter said:
>
> The GTK and wx backends have the same problem with pixel rounding on
> pcolor.  I just cured it with GTK and I bet you can do the same for
> wx.  The trick is to floor the positions and ceil the scales.  This
> will make it much more likely that the left edge of one rectangle will
> align with the right edge of another.  Eg, for the GTK backend
>
[code snipped]

I'm sure you're right. I'll try it tomorrow.

> Secondly, I am considering making a minor backend change for drawing
> 2D solids (arcs, rectangles, polygons) in the Renderer.  Rather than
> calling the functions twice, once for edge and once for face, I would
> like to define them like
>
>    def draw_rectangle(self, gcEdge, x, y, width, height, gcFace=3DNone)=
:
>
> that is, the gcFace takes the place of fill.  If None, don't fill,
> otherwise fill with the gc in gcFace.
>
> This will avoid 2 function calls per patch (once on the patch.py end
> and once in the backend forwarding it to the underlying renderer, and
> will enable backends, eg, postscript, to take advantage of a native
> fill commands.  For PS, this will at least halve the size of pcolor
> output files, which are currently obscenely large.

This seems very sensible. The changes required in backend_wx will be
minimal, and wx has a native fill (well, a brush...), so I can take
advantage of this. Halving the size of PS output is very worthwhile, and
it'll probably double the speed of pcolor on wx.

Regards

Jeremy

I just checked in to CVS a substantial refactoring of the matplotlib
axes classed, with some smaller changes to artist.Artists and their
descendants.  This won't result in any changes to the
matplotlib.matlab interface, and only minor changes to the API for
embedding matplotlib in applications (eg, a one line change to the
embedding_gtk.py example).

But it will make it easier to support, develop and maintain the
library internally.  For example, the legend command works better now,
producing a better layout, and the tick and label placement works
better.

Pretty much everything is working with known examples *except*

 1) log scaling
 2) GD backend

and these two will come along in a day or two.

So please exercise caution before checking out CVS; if you do check it
out, let me know about any bugs you find (it usually takes a while for
the mirrors to sync)

See axes.py for a summary of changes.

Thanks!
John Hunter 

>>>>> "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

The GTK and wx backends have the same problem with pixel rounding on
pcolor.  I just cured it with GTK and I bet you can do the same for
wx.  The trick is to floor the positions and ceil the scales.  This
will make it much more likely that the left edge of one rectangle will
align with the right edge of another.  Eg, for the GTK backend

    def draw_rectangle(self, gc, filled, x, y, width, height):
        """
        Draw a rectangle at lower left x,y with width and height
        If filled=True, fill the rectangle with the gc foreground
        gc is a GraphicsContext instance
        """
        self.gdkDrawable.draw_rectangle(
            gc.gdkGC, filled, int(x), self.height-int(y+height),
            int(math.ceil(width)), int(math.ceil(height)))


This worked great on my test code.

Secondly, I am considering making a minor backend change for drawing
2D solids (arcs, rectangles, polygons) in the Renderer.  Rather than
calling the functions twice, once for edge and once for face, I would
like to define them like

   def draw_rectangle(self, gcEdge, x, y, width, height, gcFace=None):

that is, the gcFace takes the place of fill.  If None, don't fill,
otherwise fill with the gc in gcFace.

This will avoid 2 function calls per patch (once on the patch.py end
and once in the backend forwarding it to the underlying renderer, and
will enable backends, eg, postscript, to take advantage of a native
fill commands.  For PS, this will at least halve the size of pcolor
output files, which are currently obscenely large.

Comments?

JDH

Hi John,

I've attached a copy of the updated backend_wx.py. Time permitting, I'll
try to verify which of the examples work correctly under my Linux install=
.

John Hunter said:
>>>>>> "Jeremy" =3D=3D Jeremy O'Donoghue <je...@o-...> writes:
>
>     Jeremy> I have just made a further update to backend_wx.  Details
>     Jeremy> below.
>
> Hi Jeremy,
>
> Thanks for the detailed update and all the progress.  I have been
> working hard on refactoring the frontend, and have made substantial
> changes to the axes classes.  This was motivated in part by your
> comment that the transform system was not clear to you, and I've
> always thought it was something of a hack.

It's good to hear this. I really was starting to dispair of getting the X
axis label in the correct place: each time I thought I had a change, it
broke something else.

> So I've cleared that up - artists now carry around their own
> transforms which contain references to the viewlim and displaylim, so
> the transforms are automagically updated in response to window resize
> events, etc....  Also, all the artists can now have their coordinates
> in arbitrary data coords (as before), or relative (0,1) axes or figure
> coords.  This makes it much more natural to specify, for example, tick
> locations, figure legends, etc...  All of the artists now handle their
> own transforms and clipping and the backend writer doesn't need to
> know anything about it.

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!

[snip]

> The reason I bring this up is I am wondering if you would like me to
> check this into CVS and let you integrate the changes now, or wait
> until I am completely finished.  Some of the features will probably
> help you -- like getting the xlabel located properly, since axis text
> locations are now done in axes coords.  All you have to do is make
> sure your axes text instance can return its window extent l,b,w,h in
> window coords and the front in will take care of the rest.  I have a
> helper function to draw a bbox around artists to help show whether the
> bbox you return is correct.

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.

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.

I'll leave implementation of printing until after the changes have
stailised a bit, as they will probably help me in this area as well.

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'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.

Regards

Jeremy

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

    Jeremy> I have just made a further update to backend_wx.  Details
    Jeremy> below.

Hi Jeremy,

Thanks for the detailed update and all the progress.  I have been
working hard on refactoring the frontend, and have made substantial
changes to the axes classes.  This was motivated in part by your
comment that the transform system was not clear to you, and I've
always thought it was something of a hack.  

So I've cleared that up - artists now carry around their own
transforms which contain references to the viewlim and displaylim, so
the transforms are automagically updated in response to window resize
events, etc....  Also, all the artists can now have their coordinates
in arbitrary data coords (as before), or relative (0,1) axes or figure
coords.  This makes it much more natural to specify, for example, tick
locations, figure legends, etc...  All of the artists now handle their
own transforms and clipping and the backend writer doesn't need to
know anything about it.

I also factored all tick, ticklabel, and gridline functionality into a
a Tick class, and legend capability into a Legend class which works
better and has more options than before.

I have made a number of API changes that will not have any effect on
the matlab interface and only a minor effect on backend
implementations (none currently on the Renderer or GraphicsContext,
but minor changes in the derived Figure class.  I have made notes on
all the API changes so I don't think you will have much difficulty
implementing them.  All of the examples except for log scaling work
perfectly, and the base code is much cleaner and I think more
readable.

The reason I bring this up is I am wondering if you would like me to
check this into CVS and let you integrate the changes now, or wait
until I am completely finished.  Some of the features will probably
help you -- like getting the xlabel located properly, since axis text
locations are now done in axes coords.  All you have to do is make
sure your axes text instance can return its window extent l,b,w,h in
window coords and the front in will take care of the rest.  I have a
helper function to draw a bbox around artists to help show whether the
bbox you return is correct.

Alternatively, I can keep these changes local until they are done and
you are ready to incorporate them.

I can't check out backend_wx.py yet because my CVS mirror is behind.
Perhaps you can just email me a copy.

JDH

I have just made a further update to backend_wx.

Details below.

regards

Jeremy

Changes are:
- Support for mousewheel: using the mousewheel anywhere on the
  toolbar or client area will perform the last selected interactive
  function (if any)
- Added a status bar to interactive figure. This gives tooltips as
  mouse travels over buttons, and indicates the last selected
  interactive function: this is the function which will be called
  when the mousewheel is used.
- Fixed bug where legend was not displayed
- Fixed bug no clipping performed on text labels
- Fixed bug script session does not exit cleanly on Windows 2000
- Fixed bug vertical text renders incorrectly. Actually this is not
  a bug, but a wxPython feature: if you select a non-TrueType font
  on Windows platform, display of rotated text is not possible. Fix
  (for demo programs) was to trap the handle 'courier' and make it
  map to a TrueType font. Longer term fix is to make sure that you
  use a TrueType font.

Not yet implemented:
- Printing
- Measure between two points

Known bugs / issues:
- Under Windows 2000, the Figure window is larger than the figure
  (OK on Linux, however)
- pcolor almost works!  See pcolor_demo.  But there appears to be a
  rounding error in the locations of the patches, shich gives a
  banded appearance to the pcolor
- xlabel location is incorrect. Actually, I'm having a great deal
  of trouble tracking this one down.
- Display of axes menu under wxGTK is ugly (this is more of a wxGTK
  implementation issue!)
- No axes selected when menu initially called - have to press the
  menu key to 'select' an axis. Behaviour here could be improved.
- Using Y axis zoom causes vertical axis text to become misplaced.
- Vertical text renders incorrectly if you use a non TrueType font
  on Windows. This is a known wxPython issue.

The following example programs work for me (subject to caveats above):

---------------------------------------------------------------
                        | Windows 2000    |  Linux            |
                        | wxPython 2.3.3  |  wxPython 2.4.2.4 |
--------------------------------------------------------------|
- arctest.py            |     OK          |
- axes_demo.py          |     OK  (1)     |
- color_demo.py         |     OK          |
- dynamic_demo.py       |     N/A (2)     |
- embedding_in_gtk.py   |     N/A (2)     |
- errorbar_demo.py      |     OK          |
- figtext.py            |     OK          |
- histogram_demo.py     |     OK          |
- interactive.py        |     N/A (2)     |
- interactive2.py       |     N/A (2)     |
- legend_demo.py        |     OK          |
- line_styles.py        |     OK          |
- log_demo.py           |     OK          |
- logo.py               |    FAIL (3)     |
- mpl_with_glade.py     |     N/A (2)     |
- mri_demo.py           |    FAIL (4)     |
- mri_demo_with_eeg.py  |    FAIL (4)     |
- multiple_figs_demo.py |     OK          |
- pcolor_demo.py        |     OK          |
- scatter_demo.py       |     OK          |
- simple_plot.py        |     OK          |
- stock_demo.py         |     OK          |
- subplot_demo.py       |     OK          |
- system_monitor.py     |     N/A (2)     |
- text_handles.py       |     OK          |
- text_themes.py        |     OK          |
- vline_demo.py         |     OK          |
---------------------------------------------------------------

(1) - Do not see data in top right axis until zoom approx x5
      (probably a bug)
(2) - Script uses GTK-specific features - cannot not run,
      but wxPython equivalent should be written.
(3) - Script fails with: No such file or directory:
      'data/membrane.dat' - get the data file!
      (probably not a bug)
(4) - Script fails with: ValueError: string size must be a multiple
      of element size. (probably not a bug)