matplotlib-devel Mailing List for matplotlib

To give a little bit more context, I want to implement a function
which attaches a figure constructed via OO interface to pyplot. 
It seems that the only way to do so now is to go over all the backends,
modify new_figure_manager to accept a figure argument, detect the 
backend used by pyplot, and use the modified new_figure_manager.

Hi everyone,
I was looking at the matplotlib backends, and I have a question about the way 
things are organized.
As of now every backend has:
* FigureManager, which corresponds to a figure + canvas + renderer + sometimes 
FigureFrame.
* Canvas, which contains a single figure and a renderer.
There is also a function new_figure_manager, which is different in every 
backend, and which is what ends up being used by pyplot.
The motivation behind this interface is not entirely clear to me. In particular 
there are several things.
* FigureManager.__init__() does not seem to be a public interface, in particular 
it is not used in pyplot.py, with new_figure_manager used instead.
* CanvasXXX.__init__() requires a figure as an argument, FigureManager requires 
Canvas as an argument, new_figure_manager does not have any arguments at all.
* If I understand correct, it does not make sense to use a FigureManager from 
one backend with a Canvas from another, is that so? If yes, why separate these 
two? A FigureManager does not make sense without a Canvas, is a Canvas useful 
without a FigureManager? Does FigureManager supply a lot of extra functionality, 
that would hurt if a Canvas is used alone?
* The multilayer structure results in all the objects holding references to each 
other: a Canvas has a renderer attribute, a Figure has a Canvas attribute. This 
makes it nearly impossible to rebind the bunch FigureManager + Canvas + Figure.
* Why to use a very limited interface provided by new_figure_manager(), as 
compared to FigureManager.__init__()?
Can you please explain what is the reason to do things this way?
Best regards,
Anton

Hi, 
I've noticed the same problem on the MacOSX backend recently (TkAgg works fine on OS X though). I assumed that it would be more than a one-line fix, therefore I did not look into it further. It would be great if your solution worked for MacOSX too!
Regards,
Ludwig

On Wed, Aug 1, 2012 at 6:44 AM, Nicolas Rougier <Nic...@in...>wrote:
>
>
> Thanks. Apart from the speed, an OpenGL backend could be also useful for
> the ipython notebook using webgl (but I'm a total newbie at webgl).
>
> Nicolas
>
>
Nicolas,
It is great to see that you have made some progress with glumpy! It is my
hope that after the effort I have been making to refactorng the Axes class
that I would then move on to studying glumpy to see how to bring that work
into matplotlib. It is certainly will not be trivial. I like the idea of
making it into a GSoC project. Maybe we can get NumFOCUS to support that
effort?
Cheers!
Ben Root

Thanks. Apart from the speed, an OpenGL backend could be also useful for the ipython notebook using webgl (but I'm a total newbie at webgl).
Nicolas
On Aug 1, 2012, at 12:07 , Damon McDougall wrote:
> On Wed, Aug 01, 2012 at 11:24:06AM +0200, Nicolas Rougier wrote:
>> 
>> 
>> Hi all,
>> 
>> 
>> I'm continuing experimenting various solution for a possible GL backend for matplotlib and I made some progress (but no integration yet).
>> 
>> You can check results (and experimenting yourself at various places, sorry for that):
>> 
>> Text : http://code.google.com/p/freetype-gl/
>> http://code.google.com/p/freetype-py/
>> 
>> Images interpolation & 3D : http://code.google.com/p/glumpy/
>> 
>> Lines/Shapes : http://code.google.com/p/gl-agg/
>> 
>> The last experiments (gl-agg) were about high-quality lines and shapes. It seems OpenGL may offer pretty decent quality (IMHO) as you can see on the various screenshots that compare agg and opengl. demo-lines.py and a demo-circles.py show zooming/panning speed (mouse drag / scroll).
>> 
>> There are still some more work to, mainly concave polygons and bezier filled shapes.
>> 
>> However, the whole integration into matplotlib may require a lot of work since OpenGL technics may radically differ from their matplotlib counterpart in some case. For example, a grid is rendered using a single shader that manages internally all the lines and ticks. Another example is image interpolation that is done entirely on the graphic card (see glumpy).
>> 
>> Also, Don't be fooled by the speed of the current demo-lines.py and demo-circles.py because they don't offer the versatility of matplotlib.
>> 
>> 
>> 
>> At this point, I may lack time to write the actual integration into matplotlib and I may not know enough the internal matplotlib machinery. Maybe this could be a future project for next year / Google summer of code ? What do you think ?
>> 
>> 
>> Nicolas
> 
> Nicholas,
> 
> There's a word for people like you: 'Hero'.
> 
> The output, in my opinion, looks very nice. Personally, I don't see
> myself using this for the two-dimensional stuff unless it's because I
> need to quickly look at something (just like you mention on the glumpy
> main page), but I think this is a winner for producing 3D plots. GL is a
> champion when it comes to 3D rendering, a la MayaVI, VTK or Paraview and
> the current mplot3d toolkit is using all of matplotlib's two dimensional
> capabilities. I would love to have something like this that mplot3d can
> hook into to produce publication-quality visualisations in
> three-dimensional space.
> 
> I have no experience with the backend side of matplotlib, I just wanted
> to say thank you for your effort :)
> 
> -- 
> Damon McDougall
> http://damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom

On Wed, Aug 01, 2012 at 11:24:06AM +0200, Nicolas Rougier wrote:
> 
> 
> Hi all,
> 
> 
> I'm continuing experimenting various solution for a possible GL backend for matplotlib and I made some progress (but no integration yet).
> 
> You can check results (and experimenting yourself at various places, sorry for that):
> 
> Text : http://code.google.com/p/freetype-gl/
> http://code.google.com/p/freetype-py/
> 
> Images interpolation & 3D : http://code.google.com/p/glumpy/
> 
> Lines/Shapes : http://code.google.com/p/gl-agg/
> 
> The last experiments (gl-agg) were about high-quality lines and shapes. It seems OpenGL may offer pretty decent quality (IMHO) as you can see on the various screenshots that compare agg and opengl. demo-lines.py and a demo-circles.py show zooming/panning speed (mouse drag / scroll).
> 
> There are still some more work to, mainly concave polygons and bezier filled shapes.
> 
> However, the whole integration into matplotlib may require a lot of work since OpenGL technics may radically differ from their matplotlib counterpart in some case. For example, a grid is rendered using a single shader that manages internally all the lines and ticks. Another example is image interpolation that is done entirely on the graphic card (see glumpy).
> 
> Also, Don't be fooled by the speed of the current demo-lines.py and demo-circles.py because they don't offer the versatility of matplotlib.
> 
> 
> 
> At this point, I may lack time to write the actual integration into matplotlib and I may not know enough the internal matplotlib machinery. Maybe this could be a future project for next year / Google summer of code ? What do you think ?
> 
> 
> Nicolas
Nicholas,
There's a word for people like you: 'Hero'.
The output, in my opinion, looks very nice. Personally, I don't see
myself using this for the two-dimensional stuff unless it's because I
need to quickly look at something (just like you mention on the glumpy
main page), but I think this is a winner for producing 3D plots. GL is a
champion when it comes to 3D rendering, a la MayaVI, VTK or Paraview and
the current mplot3d toolkit is using all of matplotlib's two dimensional
capabilities. I would love to have something like this that mplot3d can
hook into to produce publication-quality visualisations in
three-dimensional space.
I have no experience with the backend side of matplotlib, I just wanted
to say thank you for your effort :)
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Hi all,
I'm continuing experimenting various solution for a possible GL backend for matplotlib and I made some progress (but no integration yet).
You can check results (and experimenting yourself at various places, sorry for that):
Text : http://code.google.com/p/freetype-gl/
 http://code.google.com/p/freetype-py/
Images interpolation & 3D : http://code.google.com/p/glumpy/
Lines/Shapes : http://code.google.com/p/gl-agg/
The last experiments (gl-agg) were about high-quality lines and shapes. It seems OpenGL may offer pretty decent quality (IMHO) as you can see on the various screenshots that compare agg and opengl. demo-lines.py and a demo-circles.py show zooming/panning speed (mouse drag / scroll).
There are still some more work to, mainly concave polygons and bezier filled shapes.
However, the whole integration into matplotlib may require a lot of work since OpenGL technics may radically differ from their matplotlib counterpart in some case. For example, a grid is rendered using a single shader that manages internally all the lines and ticks. Another example is image interpolation that is done entirely on the graphic card (see glumpy).
Also, Don't be fooled by the speed of the current demo-lines.py and demo-circles.py because they don't offer the versatility of matplotlib.
At this point, I may lack time to write the actual integration into matplotlib and I may not know enough the internal matplotlib machinery. Maybe this could be a future project for next year / Google summer of code ? What do you think ?
Nicolas