matplotlib-devel Mailing List for matplotlib

>>>>> "Jody" == Jody Winston <jos...@ma...> writes:
 Jody> The real reason that I am working on Cairo and matplotlib is
 Jody> that I want a portable way to display output from ATT's
 Jody> graphviz. From my quick look through matplotlib's code, it
 Jody> looks like this may be hard to do. So, if I continue this
 Jody> project, I'll also be asking how to render ploygons,
 Jody> ellipses, and text. Do you think that matplotlib is a good
 Jody> fit given my requirements?
Without commenting on goodness of fit, I'll add that matplotlib has
fundamental elements for polygons (matplotlib.patches.Polygon) and
text (matplotlib.text.Text) and it would be straightforward to add a
dedicated ellipse class (currently we just use polygons for ellipses)
and Ted also has an interest in creating an ellipse class for scale
free renderering, eg in the postscript backend.
JDH

Jody,
I have someone working on a Qt front end (using Agg for rendering). He's 
only able to put in roughly 1 day/week and with the holidays coming up I'm 
not sure when it's going to be finished. We're looking in to the 
possibility of being able to contribute this back to matplotlib (if John 
wants it) but there are legal issues on my end that need to get resolved 
before I'll know if it's possible.
FYI: If you want to render the output from graphviz, have you looked at 
dot? The C/C++ tool doxygen uses graphviz/dot to render inheritance 
diagrams and place them in web pages (with click-able boxes no less).
Ted
At 11:15 AM 12/9/2004, Jody Winston wrote:
>John Hunter writes:
> > >>>>> "Jody" == Jody Winston <jos...@ma...> writes:
> >
> > Jody> Any pointers on either finding a Qt backend or writing one?
> > Jody> Thanks,
> >
> > Hi Jody,
> >
> > Sorry for the delay in getting back to you - I've been out of town for
> > a week.
> >
> > There have been several people who have expressed interest in A QT
> > backend - most recently Ted Drain at the JPL. Perhaps you two could
> > coordinate your efforts?
>
>I'd be happy to work with Ted.
>
> > The first place to start is in the file
> > matplotlib/backends/backend_template.py, which serves as a template
> > for backend writers and gives some instructions. I would follow the
> > model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
> > WXAgg, which use Agg to render the image and place it in the GUI
> > canvas. This is a lot less work and you automiatically get the latest
> > matplotlib feature set for free. The basic idea is to use a GUI
> > independent image library that can then be reused across GUIs.
> >
> > The backends have to implement concrete versions of several interface
> > classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
> > FigureManagerBase, NavigationToolbar2. If you opt to use Agg (or
> > Cairo) to do the drawing for you, you can leave out RendererBase and
> > GraphicsContextBase, which are the two that require the most work.
>
>I've also built a SWIG interface for Cairo so that I can embed it in a
>Qt application.
>
>The real reason that I am working on Cairo and matplotlib is that I
>want a portable way to display output from ATT's graphviz. From my
>quick look through matplotlib's code, it looks like this may be hard
>to do. So, if I continue this project, I'll also be asking how to
>render ploygons, ellipses, and text. Do you think that matplotlib is
>a good fit given my requirements?
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On Thu, 2004年12月09日 at 13:15 -0600, Jody Winston wrote:
> I've also built a SWIG interface for Cairo so that I can embed it in a
> Qt application.
Matplotlib already supports Cairo rendering - it uses the Python Cairo
bindings PyCairo. For Qt to work with PyCairo I think you would just
need to write one function that connects an xlib target surface to Qt,
and then you would get all the matplotlib Cairo rendering done for free.
Steve

John Hunter writes:
 > >>>>> "Jody" == Jody Winston <jos...@ma...> writes:
 > 
 > Jody> Any pointers on either finding a Qt backend or writing one?
 > Jody> Thanks,
 > 
 > Hi Jody,
 > 
 > Sorry for the delay in getting back to you - I've been out of town for
 > a week.
 > 
 > There have been several people who have expressed interest in A QT
 > backend - most recently Ted Drain at the JPL. Perhaps you two could
 > coordinate your efforts?
I'd be happy to work with Ted.
 > The first place to start is in the file
 > matplotlib/backends/backend_template.py, which serves as a template
 > for backend writers and gives some instructions. I would follow the
 > model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
 > WXAgg, which use Agg to render the image and place it in the GUI
 > canvas. This is a lot less work and you automiatically get the latest
 > matplotlib feature set for free. The basic idea is to use a GUI
 > independent image library that can then be reused across GUIs. 
 > 
 > The backends have to implement concrete versions of several interface
 > classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
 > FigureManagerBase, NavigationToolbar2. If you opt to use Agg (or
 > Cairo) to do the drawing for you, you can leave out RendererBase and
 > GraphicsContextBase, which are the two that require the most work.
I've also built a SWIG interface for Cairo so that I can embed it in a
Qt application.
The real reason that I am working on Cairo and matplotlib is that I
want a portable way to display output from ATT's graphviz. From my
quick look through matplotlib's code, it looks like this may be hard
to do. So, if I continue this project, I'll also be asking how to
render ploygons, ellipses, and text. Do you think that matplotlib is
a good fit given my requirements?

>>>>> "Jody" == Jody Winston <jos...@ma...> writes:
 Jody> Any pointers on either finding a Qt backend or writing one?
 Jody> Thanks,
Hi Jody,
Sorry for the delay in getting back to you - I've been out of town for
a week.
There have been several people who have expressed interest in A QT
backend - most recently Ted Drain at the JPL. Perhaps you two could
coordinate your efforts?
The first place to start is in the file
matplotlib/backends/backend_template.py, which serves as a template
for backend writers and gives some instructions. I would follow the
model of one of the *Agg backends, eg TkAgg, GTKAgg, FLTKAgg and
WXAgg, which use Agg to render the image and place it in the GUI
canvas. This is a lot less work and you automiatically get the latest
matplotlib feature set for free. The basic idea is to use a GUI
independent image library that can then be reused across GUIs. 
The backends have to implement concrete versions of several interface
classes: RendererBase, GraphicsContextBase, FigureCanvasBase,
FigureManagerBase, NavigationToolbar2. If you opt to use Agg (or
Cairo) to do the drawing for you, you can leave out RendererBase and
GraphicsContextBase, which are the two that require the most work.
JDH

On the users list, I recently discussed renaming the matlab namespace
to pylab out of trademark concerns
 http://sourceforge.net/mailarchive/message.php?msg_id=10174321
This change is now in CVS. For the next few releases, importing
matplotlib.matlab will work but issue a deprecation warning. I also
added pylab.py to site-packages, and the suggested way of importing
the pylab namespace is
 from pylab import blah, blah
which is a wrapper around
 from matplotlib.pylab import blah, blah
There is a script at http://matplotlib.sf.net/matplotlib_to_pylab.py
to recursively convert names files and directories to the new naming
convention. Read the header to see which cases it handles and which
it does not.
Please update your repositories and test the new changes and
conversion script, which will go into the 0.65 release.
JDH

I've split backend_gtk.py into two parts:
backend_gdk.py - an image backend, like Agg and Cairo.
backend_gtk.py - an GUI backend, that uses gdk rendering
I don't think that a gdk backend is that much use by itself (since Agg
is probably better for most people to use), but I think it has these
benefits:
- the split is more consistent with the way Agg/GTKAgg and
Cairo/GTKCairo are written - the rendering (image backend) is separated
from the GUI.
- it allows me to run examples/backend_driver.py on gdk (without having
gtk widgets popup on screen) and compare performance etc to Agg and
Cairo.
- it makes it easier to delete GDK rendering (while keeping the GTK GUI)
at a later date, if it is no longer required.
Here's the backend_driver results I got for some of the backends,
fastest first:
Backend Template took 0.89 minutes to complete
 template ratio 1.000, template residual 0.000
Backend SVG took 1.06 minutes to complete
 template ratio 1.185, template residual 0.166
Backend PS took 1.32 minutes to complete
 template ratio 1.480, template residual 0.429
Backend Agg took 1.36 minutes to complete
 template ratio 1.519, template residual 0.464
Backend GDK took 1.88 minutes to complete
 template ratio 2.101, template residual 0.984
Backend Cairo took 2.11 minutes to complete
 template ratio 2.358, template residual 1.214
Cairo is slow compared to Agg, but has similar performance to GDK.
This makes sense since GDK and Cairo are both written in Python, 
which much of Agg is written in C++.
Steve