matplotlib-devel Mailing List for matplotlib (Page 5)

Le 07/08/12 01:17, Peter Würtz a écrit :
> Hi!
> I would like to ask for a code review for a new backend I wrote for creating
> figures with Xelatex/Lualatex. It uses the PGF (Tikz) Package for all
> drawing operations and enables full unicode support and typesetting of
> texts/formulas using Latex. This way, the figures created fit perfectly in
> Latex documents. Furthermore, Xelatex/Lualatex is able to use the fonts
> installed on your operating system. The drawing commands of the PGF pictures
> can be included in Latex documents or can be directly compiled to PDF by the
> backend.
>
> Github project for hosting the code, usage instructions and examples:
> https://github.com/pwuertz/matplotlib-backend-pgf
>
> A document demonstrating the benefits of using Xelatex/PGF:
> https://github.com/pwuertz/matplotlib-backend-pgf/raw/master/demo/demo.pdf
>
> Gallery of the matplotlib examples processed with backend_pgf:
> https://github.com/pwuertz/matplotlib-backend-pgf/wiki/Examples%20Gallery
> A few exceptions are known to fail due to Latex incompatible math-text.
>
> This is a matplotlib branch set up as suggested in the matplotlib developer
> wiki. It includes the code from above and adds new rc-parameters and the
> '.pgf' file type.
> https://github.com/pwuertz/matplotlib/compare/master...pgf-backend
>
> Discussions are usually taking place at the github diff, right? I hope
> you'll find this an interesting option for creating figures with matplotlib.
>
> Cheers,
> Peter
Very interesting work. Thanks.
Is there any reason that the generated figure could not
be used with pdflatex ?
I ask the question before giving it a try (I use pdflatex).
Regards,
David

Hi,
Great post and I feel the three-way split method you're talking about could also be incredibly useful for the GL backend (see my previous post about GL backend). 
Nicolas
On Aug 6, 2012, at 23:59 , Michael Droettboom wrote:
> For anyone who's interested, I've started blogging about my initial 
> thinking on client-side plotting in the web browser with matplotlib here:
> 
> http://mdboom.github.com/
> 
> (I hope to get this aggregated into planet.scipy.org soon, too).
> 
> Mike
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi!
I would like to ask for a code review for a new backend I wrote for creating
figures with Xelatex/Lualatex. It uses the PGF (Tikz) Package for all
drawing operations and enables full unicode support and typesetting of
texts/formulas using Latex. This way, the figures created fit perfectly in
Latex documents. Furthermore, Xelatex/Lualatex is able to use the fonts
installed on your operating system. The drawing commands of the PGF pictures
can be included in Latex documents or can be directly compiled to PDF by the
backend.
Github project for hosting the code, usage instructions and examples:
https://github.com/pwuertz/matplotlib-backend-pgf
A document demonstrating the benefits of using Xelatex/PGF:
https://github.com/pwuertz/matplotlib-backend-pgf/raw/master/demo/demo.pdf
Gallery of the matplotlib examples processed with backend_pgf:
https://github.com/pwuertz/matplotlib-backend-pgf/wiki/Examples%20Gallery
A few exceptions are known to fail due to Latex incompatible math-text.
This is a matplotlib branch set up as suggested in the matplotlib developer
wiki. It includes the code from above and adds new rc-parameters and the
'.pgf' file type.
https://github.com/pwuertz/matplotlib/compare/master...pgf-backend
Discussions are usually taking place at the github diff, right? I hope
you'll find this an interesting option for creating figures with matplotlib.
Cheers,
Peter
-- 
View this message in context: http://old.nabble.com/Asking-for-code-review%3A-Xelatex---PGF-backend-tp34263853p34263853.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

For anyone who's interested, I've started blogging about my initial 
thinking on client-side plotting in the web browser with matplotlib here:
 http://mdboom.github.com/
(I hope to get this aggregated into planet.scipy.org soon, too).
Mike

On 08/06/2012 02:10 PM, Benjamin Root wrote:
>
>
> On Tue, Dec 6, 2011 at 4:15 PM, Jim Hunziker <lan...@gm... 
> <mailto:lan...@gm...>> wrote:
>
> I'm not sure if this is the right place to report this, but the link
> to Python(x, y) on
> http://matplotlib.sourceforge.net/users/installing.html points to a
> page that no longer exists.
>
> --
> Jim Hunziker
>
>
> Starting to go back over my backlog of emails. I can confirm that 
> this is the case.
I assume we should just link to:
 http://www.pythonxy.com/
Correct? If so, I can fix this in the repository.
Mike

On Tue, Dec 6, 2011 at 4:15 PM, Jim Hunziker <lan...@gm...> wrote:
> I'm not sure if this is the right place to report this, but the link
> to Python(x, y) on
> http://matplotlib.sourceforge.net/users/installing.html points to a
> page that no longer exists.
>
> --
> Jim Hunziker
>
>
Starting to go back over my backlog of emails. I can confirm that this is
the case.
Ben Root

Hi everyone,
I was looking at the Axes code. In particular I think of implementing a 
Axes.lines method, which would unify Axes.hlines and Axes.vlines, reducing the 
required code maintenance. I have also studied the code of these two methods, 
and I have now several questions/remarks.
 * hlines(y=iter(xrange(5), ...) is declared to work, since 
 "*y*: a 1-D numpy array or iterable." However, this will produce an error in
 the end, because y ends up passed to a np.asarray, instead of np.fromiter.
 This bug is easy to fix, however I would like to know what is the desired
 overall behavior of the function, see the following.
 * These two functions are designed to pass arguments to 
 collections.LineCollection, which actually is ok with taking an iterable as 
an
 argument, however these functions forms first a numpy array, then a list of
 tuples. The allowed arguments to these functions, in the meantime aren't even
 homogeneous: some are required to be scalars or iterators, some scalars or
 numpy arrays.
 * Scalars are interpreted as constant iterators. Would it be also a reasonable
 behavior to interpret shorter iterators as cycles, or should only scalars be
 allowed as special values?
 * When checking for scalars is there a reason to favor cbook.scalar, which uses
 a crude method over np.isscalar, which is presumably more thorough?
 * A somewhat related question: unit converter interface specifies that it 
should 
 work on sequences (objects which have length and many other extra 
properties).
 At the same time, unit conversion in several parts of code is applied to
 objects which are allowed to be just iterators. Should unit conversion
 actually also work on iterators, or should matplotlib not take anywhere where
 unit conversion is used? By the way, units.ConversionInterface could benefit
 from using python abc abstract base classes module. Does it make sense to 
add?
 * Finally, does it make sense to combine hlines and vlines?
Best regards,
Anton Akhmerov
 

As I alluded to yesterday, I think it's time to start formalizing, ever 
so slightly, the process to get larger chunks of work done on the code 
base. Therefore, I propose the concept of "matplotlib enhancement 
proposals" to track this work.
I've created a simple "MEP template" on the wiki, and written the first, 
very simple, MEP.
https://github.com/matplotlib/matplotlib/wiki
Let me know if you have any feedback on the template. I've tried to 
walk the line of including enough necessary information, while not being 
overly burdensome.
I look forward to seeing what other MEPs we dream up!
Mike

I have created a Google Calendar for tracking release schedule dates. 
This may also include other matplotlib-related events in the future.
At the moment, this includes the dates John outlined for the next release.
The URLs for subscribing to the calendar are on the wiki here:
https://github.com/matplotlib/matplotlib/wiki
Mike

On Aug 2, 2012, at 5:25 PM, John Hunter wrote:
>
> I also extend my heartfelt thanks to Perry Greenfield and STScI. They
> have been supporting matplotlib since 2004 with ideas, code and
> developer resources. They employ Michael currently, and are part of
> the reason why he is able to take on the leadership of this large
> project.
>
John, it has been our great fortune have joined the matplotlib effort. 
It saved us an enormous effort. It has been an incredible pleasure 
working with you. I'm not sure you realize how very much Mike and I 
hope you can rejoin the matplotlib effort. It will always be there for 
you.
Perry

I couldn't put an exact date on when John began matplotlib, but its 
sourceforge repository was registered in June of 2003. Python 2.2 was 
the latest version available. Microsoft Windows XP was on the shelves, 
Mac OS X was new to the scene, and Linux had yet to be made easy by the 
likes of Ubuntu and Fedora. Facebook, Twitter and the smartphone 
weren't yet available. And the idea of richly interactive and 
productive applications running in the cloud was still considered 
crazy. A decade is a long time for an open source project, and it's a 
testament to John's hard work and keen decision-making that matplotlib 
has thrived for so long and grown into such a large community of smart 
and talented users and developers. Bravo, John.
To remain relevant in its second decade, matplotlib is being pulled 
simultaneously in two directions. On the one hand, to handle larger and 
more complex data, it needs to get closer to the hardware to make better 
use of GPUs and multicore CPUs. On the other hand, it needs to become a 
first-class member of the most important GUI of our time, the web 
browser, and to do so without sacrificing any of the power and 
flexibility it gets from being a Python library. Challenging stuff, but 
not unattainable given the enormous brain trust we've got here.
Procedurally, one thing I've been feeling rather acutely lately is that 
the firehose of github issues is not always the best way to track larger 
changes. I'd like to propose that we set up an informal system of 
"Matplotlib Enhancement Proposals" (MEPs) to manage larger changes to 
matplotlib that might cut across a number of different subsystems. 
Numpy puts these in their source code repository, but we may just want 
to use the github wiki to make it even easier for non-developers to 
contribute ideas. I'm not envisioning anything super formal here -- 
just something to keep track of the larger goals that won't get lost 
among hundreds of smaller issues. Details can be discussed here (I'd 
love suggestions from other projects) and I'll set something up soon. 
I'm sure we all have our own pet projects we'd like to do "time willing" 
and I look forward to discussing and making headway on some of those.
And back to the immediate future: we've got a release to get out: the 
first release to support Python 3.x. Exciting times. Details to follow 
in another e-mail thread.
John, thanks again for the honor and I hope I can follow your example of 
leadership. They are big shoes to fill.
Mike
On 08/02/2012 05:25 PM, John Hunter wrote:
> It is a great honor for me to announce that Michael Droettboom has
> agreed to take on the role of lead developer of matplotlib. Since
> Michael joined the project in 2007, he has been responsible for much
> of the code that brought matplotlib from being an excellent tool to a
> world class one. No one in the world understands the code from the
> inside out like he does, and many of his contributions, while often
> unseen at the surface, have laid the foundation for matplotlib to
> reach further into the wild and wonderful things it can now do.
>
> To name a few of his contributions: generic, optimized caching
> transformations; dramatic backend simplification and rationalization;
> countless optimizations; implementation of Knuth mathtex layouts;
> python3 support, and dolphins! I like to tell people Michael codes
> with the force of ten men, and he's an incredible asset to our team.
>
> My role has been significantly diminished of late -- although I have
> been the nominal lead developer, in practice I have been a release
> manager. Unfortunately, I need to take some time to focus on family
> health issues, but will continue to follow development and make
> contributions as I can. We'll be looking for a release manager soon,
> and if you are interested in stepping up, we'll welcome the effort.
> We have a wonderful distributed development team using github pull
> requests, and the line between core developers, project leaders and
> plain-ole contributers is blurry. But I think it helps to have
> someone thinking about the project as a whole, who is willing and able
> to make decisions when necessary, and no one is better suited to doing
> this than Michael.
>
> I also extend my heartfelt thanks to Perry Greenfield and STScI. They
> have been supporting matplotlib since 2004 with ideas, code and
> developer resources. They employ Michael currently, and are part of
> the reason why he is able to take on the leadership of this large
> project.
>
> Michael, many thanks.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

John, I wish all the best you and your family. You have been the hub
of a truly brilliant project for which I can only see its userbase
continuing to expand.
Mike, your appointment is thoroughly deserved and I look forward to
continuing to work closely with you and the rest of the matplotlib
team. Congrats!
Phil
On 2 August 2012 23:06, Benjamin Root <ben...@ou...> wrote:
>
>
> On Thursday, August 2, 2012, John Hunter wrote:
>>
>> It is a great honor for me to announce that Michael Droettboom has
>> agreed to take on the role of lead developer of matplotlib. Since
>> Michael joined the project in 2007, he has been responsible for much
>> of the code that brought matplotlib from being an excellent tool to a
>> world class one. No one in the world understands the code from the
>> inside out like he does, and many of his contributions, while often
>> unseen at the surface, have laid the foundation for matplotlib to
>> reach further into the wild and wonderful things it can now do.
>>
>> To name a few of his contributions: generic, optimized caching
>> transformations; dramatic backend simplification and rationalization;
>> countless optimizations; implementation of Knuth mathtex layouts;
>> python3 support, and dolphins! I like to tell people Michael codes
>> with the force of ten men, and he's an incredible asset to our team.
>>
>> My role has been significantly diminished of late -- although I have
>> been the nominal lead developer, in practice I have been a release
>> manager. Unfortunately, I need to take some time to focus on family
>> health issues, but will continue to follow development and make
>> contributions as I can. We'll be looking for a release manager soon,
>> and if you are interested in stepping up, we'll welcome the effort.
>> We have a wonderful distributed development team using github pull
>> requests, and the line between core developers, project leaders and
>> plain-ole contributers is blurry. But I think it helps to have
>> someone thinking about the project as a whole, who is willing and able
>> to make decisions when necessary, and no one is better suited to doing
>> this than Michael.
>>
>> I also extend my heartfelt thanks to Perry Greenfield and STScI. They
>> have been supporting matplotlib since 2004 with ideas, code and
>> developer resources. They employ Michael currently, and are part of
>> the reason why he is able to take on the leadership of this large
>> project.
>>
>> Michael, many thanks.
>
>
>
> Congrats, Michael!
>
> Ben Root
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thursday, August 2, 2012, John Hunter wrote:
> It is a great honor for me to announce that Michael Droettboom has
> agreed to take on the role of lead developer of matplotlib. Since
> Michael joined the project in 2007, he has been responsible for much
> of the code that brought matplotlib from being an excellent tool to a
> world class one. No one in the world understands the code from the
> inside out like he does, and many of his contributions, while often
> unseen at the surface, have laid the foundation for matplotlib to
> reach further into the wild and wonderful things it can now do.
>
> To name a few of his contributions: generic, optimized caching
> transformations; dramatic backend simplification and rationalization;
> countless optimizations; implementation of Knuth mathtex layouts;
> python3 support, and dolphins! I like to tell people Michael codes
> with the force of ten men, and he's an incredible asset to our team.
>
> My role has been significantly diminished of late -- although I have
> been the nominal lead developer, in practice I have been a release
> manager. Unfortunately, I need to take some time to focus on family
> health issues, but will continue to follow development and make
> contributions as I can. We'll be looking for a release manager soon,
> and if you are interested in stepping up, we'll welcome the effort.
> We have a wonderful distributed development team using github pull
> requests, and the line between core developers, project leaders and
> plain-ole contributers is blurry. But I think it helps to have
> someone thinking about the project as a whole, who is willing and able
> to make decisions when necessary, and no one is better suited to doing
> this than Michael.
>
> I also extend my heartfelt thanks to Perry Greenfield and STScI. They
> have been supporting matplotlib since 2004 with ideas, code and
> developer resources. They employ Michael currently, and are part of
> the reason why he is able to take on the leadership of this large
> project.
>
> Michael, many thanks.
>
Congrats, Michael!
Ben Root

It is a great honor for me to announce that Michael Droettboom has
agreed to take on the role of lead developer of matplotlib. Since
Michael joined the project in 2007, he has been responsible for much
of the code that brought matplotlib from being an excellent tool to a
world class one. No one in the world understands the code from the
inside out like he does, and many of his contributions, while often
unseen at the surface, have laid the foundation for matplotlib to
reach further into the wild and wonderful things it can now do.
To name a few of his contributions: generic, optimized caching
transformations; dramatic backend simplification and rationalization;
countless optimizations; implementation of Knuth mathtex layouts;
python3 support, and dolphins! I like to tell people Michael codes
with the force of ten men, and he's an incredible asset to our team.
My role has been significantly diminished of late -- although I have
been the nominal lead developer, in practice I have been a release
manager. Unfortunately, I need to take some time to focus on family
health issues, but will continue to follow development and make
contributions as I can. We'll be looking for a release manager soon,
and if you are interested in stepping up, we'll welcome the effort.
We have a wonderful distributed development team using github pull
requests, and the line between core developers, project leaders and
plain-ole contributers is blurry. But I think it helps to have
someone thinking about the project as a whole, who is willing and able
to make decisions when necessary, and no one is better suited to doing
this than Michael.
I also extend my heartfelt thanks to Perry Greenfield and STScI. They
have been supporting matplotlib since 2004 with ideas, code and
developer resources. They employ Michael currently, and are part of
the reason why he is able to take on the leadership of this large
project.
Michael, many thanks.

I will also try to look at the GL backend again.
One of the main difficulty I see is to handle GPU memory properly. For example, to draw a line collection (using OpenGL) I first build a vertex buffer that is sent to the GPU and then offset/translate/rotate can be done locally/globally very efficiently without rebuilding the vertex buffer. In the template backend however, the "draw_path" function receives a path to be rendered and I need to ensure it is build only once and only applying transforms for subsequent calls. Also, Mike explained the overall situation very well (last year on this mailing list) regarding backend performances.
As for NumFOCUS, what kind of support do you expect ?
Nicolas
On Aug 1, 2012, at 16:15 , Benjamin Root wrote:
> 
> 
> 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
> 

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