Thread: [matplotlib-devel] Qt backend

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Any pointers on either finding a Qt backend or writing one?

Thanks,

Jody Winston

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

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?

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

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

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

I've been doing some profiling using
'hotshotmain.py simple_plot.py -dAgg >/tmp/hs-out 2>&1'
(with the Tools/scripts/hotshotmain.py script from the Python src
distribution)

I looked at the output and noticed that the pytz module takes up a fair
amount of the time. Which is a bit unexpected for simple_plot.py which
does not have any dates!
I commented out the 'dates' imports in pylab.py and axes.py and
performance increased 13%. It seemed strange for an import to have such
a large effect, but when I looked at dates.py I saw that it executes
code - it calls timezone() 9 times - a function which does further
imports which read in a lot of data.
If I restore the 'dates' imports and just comment out the 9 timezone()
calls in dates.py the speedup is 11% and it saves around 3,000 function
calls!

I suggest
- for optional modules (like dates), only import them when they are
required (when the plot actually has a date)
- for all modules try to minimise the amount of code that will execute
upon import, especially function calls.

What do you think?

Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I suggest - for optional modules (like dates), only import
    Steve> them when they are required (when the plot actually has a
    Steve> date) - for all modules try to minimise the amount of code
    Steve> that will execute upon import, especially function calls.

    Steve> What do you think?

Sounds great.  Thanks for tracking this one down.  A 10% speedup is
well worth it.  It sounds like the dates module should also cache the
timezone info.  Do you want to take the lead on this one?  

JDH

On Sun, 2004-12-12 at 15:09 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> I suggest - for optional modules (like dates), only import
>     Steve> them when they are required (when the plot actually has a
>     Steve> date) - for all modules try to minimise the amount of code
>     Steve> that will execute upon import, especially function calls.
> 
>     Steve> What do you think?
> 
> Sounds great.  Thanks for tracking this one down.  A 10% speedup is
> well worth it.  It sounds like the dates module should also cache the
> timezone info.  Do you want to take the lead on this one?  
> 
> JDH
Out of these timezones in dates.py
UTC      = timezone('UTC')
Eastern  = timezone('US/Eastern')
Central  = timezone('US/Central')
Mountain = timezone('US/Mountain')
Pacific  = timezone('US/Pacific')
London   = timezone('Europe/London')
Paris    = timezone('Europe/Paris')
Berlin   = timezone('Europe/Berlin')
Moscow   = timezone('Europe/Moscow')

As far as I can see the only timezones actually used are
UTC - as a function default value, and Pacific - used in __main__
Is it OK to remove all the unused ones, or is there something that
relies on them?

Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> Out of these timezones in dates.py UTC = timezone('UTC')
    Steve> Eastern = timezone('US/Eastern') Central =
    Steve> timezone('US/Central') Mountain = timezone('US/Mountain')
    Steve> Pacific = timezone('US/Pacific') London =
    Steve> timezone('Europe/London') Paris = timezone('Europe/Paris')
    Steve> Berlin = timezone('Europe/Berlin') Moscow =
    Steve> timezone('Europe/Moscow')

    Steve> As far as I can see the only timezones actually used are
    Steve> UTC - as a function default value, and Pacific - used in
    Steve> __main__ Is it OK to remove all the unused ones, or is
    Steve> there something that relies on them?

Well, I provided these for convenience for people to import from the
dates module.  It never occurred to me that simply instantiating 7
objects would carry such a performance hit.  However, it doesn't
appear that I documented this anywhere, so it should be safe to remove
them - just make a note in the API_CHANGES file that they are gone and
I'll mention it in the release notes.

JDH