matplotlib-devel — matplotlib developers

[matplotlib-devel] Asking for code review: Xelatex / PGF backend

[Peter W. <pw...@go...>]

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.

[matplotlib-devel] Client-side plotting

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] bad link on matplotlib website

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] bad link on matplotlib website

[Benjamin R. <ben...@ou...>]

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

[matplotlib-devel] Axes.hlines cleanup

[Anton A. <ant...@gm...>]

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
 

[matplotlib-devel] Introducing MEPs

[Michael D. <md...@st...>]

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

[matplotlib-devel] matplotlib events calendar

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] ANN: Michael Droettboom, matplotlib lead developer

[Perry G. <pe...@st...>]

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

Re: [matplotlib-devel] [Matplotlib-users] ANN: Michael Droettboom, matplotlib lead developer

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] ANN: Michael Droettboom, matplotlib lead developer

[Phil E. <pel...@gm...>]

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
>

Re: [matplotlib-devel] ANN: Michael Droettboom, matplotlib lead developer

[Benjamin R. <ben...@ou...>]

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

[matplotlib-devel] ANN: Michael Droettboom, matplotlib lead developer

[John H. <jd...@gm...>]

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.

Re: [matplotlib-devel] Some update on GL backend

[Nicolas R. <Nic...@in...>]

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
> 

Re: [matplotlib-devel] Backends object structure

[Anton A. <ant...@gm...>]

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.

[matplotlib-devel] Backends object structure

[Anton A. <ant...@gm...>]

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

Re: [matplotlib-devel] Matplotlib Qt4Agg backend ignores 'resize_event'

[Ludwig S. <lud...@gm...>]

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

Re: [matplotlib-devel] Some update on GL backend

[Benjamin R. <ben...@ou...>]

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

Re: [matplotlib-devel] Some update on GL backend

[Nicolas R. <Nic...@in...>]

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

Re: [matplotlib-devel] Some update on GL backend

[Damon M. <dam...@gm...>]

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

[matplotlib-devel] Some update on GL backend

[Nicolas R. <Nic...@in...>]

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

Re: [matplotlib-devel] bugs/difficulties encountered while creating interactive SVG

[Michael D. <md...@st...>]

On 07/29/2012 11:33 AM, Dimitrios Apostolou wrote:
>> ------------------------------------------------------------------------------
>> 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/
> I didn't add this signature! Either Sourceforge is advertising through
> email now too, or my MUA has a virus...
>
For better or worse, Sourceforge has been doing this for some time.

Mike

Re: [matplotlib-devel] bugs/difficulties encountered while creating interactive SVG

[Dimitrios A. <ji...@gm...>]

On Sat, 28 Jul 2012, Dimitrios Apostolou wrote:

> Even though some things needed time-consuming hacks, matplotlib worked
> fine. Thanks for your work on this fantastic library!  And if you are
> curious you can see my automatic generated graphs (temporarily) at:
>
> http://teras-ics.mooo.com:8003

Sorry but my primary PC died last night, this page will be unavailable for 
some time. :-(


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

I didn't add this signature! Either Sourceforge is advertising through 
email now too, or my MUA has a virus...


Dimitris

Re: [matplotlib-devel] Matplotlib Qt4Agg backend ignores 'resize_event'

[Stefan H. <shm...@gm...>]

Collin,

My problem is not with the actual "resize" functionality, which works fine,
but with attaching a callback to a resize_event ("say_hello" in my example).
Specifically, I have a figure that uses blitting, i.e., saves the background
and only updates some artists as a function of events in another figure.
Obviously, when the user resizes the blitting figure, the background changes
and the snapshot image has to be regenerated. Hence my need to attach a
callback to a resize event. This works fine in other backends that support
blitting, but not in Qt4Agg.

The reason why it doesn't work lies in
lib/matplotlib/backends/backend_qt4.py, where the last line is missing in: 

def resizeEvent( self, event ):
    ...
    FigureCanvasBase.resize_event(self) 

I was hoping that someone could confirm that this is a bug and that adding
the line is the correct fix for the problem. I was then going to file a bug
report.

Thanks,
Stefan

-- 
View this message in context: http://old.nabble.com/Matplotlib-Qt4Agg-backend-ignores-%27resize_event%27-tp34205981p34226500.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

[matplotlib-devel] bugs/difficulties encountered while creating interactive SVG

[Dimitrios A. <ji...@gm...>]

Hello list,

I was trying to create some interactive SVGs with matplotlib and I faced 
the following issues. Some maybe bugs, some other just missing 
functionality. I'm just summarising my experience so that you are aware of 
the issues.

First of all I used git-head from a couple of monts ago with python-3.2, 
and I'm quite happy that it worked. :-) My target was to make the dots in 
a plot(x,y,"-o") graph clickable. Here are the issues I faced:

* I didn't find a way to set an "id" attribute for each marker. Googling
   revealed that I should probably call set_gid() but I had no success. So
   I stored the whole XML file into memory and searched for the <use> tags
   inside <g id="line2d_1">. The ideal would have been for each <use> to
   have a specific id, or at least the <g> containing the <use>s.

* pylab.savefig(f, format="svg") never worked whenever f was sys.stdout or
   io.StringIO. It seems that it err'ed on every file that didn't support
   open(). My workaround was to write to a tempfile and read back. Maybe
   support for this can be added together with support for already opened
   files, so that the with-statement works? I /think/ errors were like
   the following:

File "~/dist/src/matplotlib-git/matplotlib/build/lib.linux-i686-3.2/matplotlib/backends/backend_svg.py", 
line 1101, in print_svg
     return self._print_svg(filename, svgwriter, fh_to_close, **kwargs) 
UnboundLocalError: local variable 'svgwriter' referenced before assignment

* I couldn't use pylab.ticklabel_format() with SVG engine (I was trying to
   apply an offset to the xticks labels), error message was the following,
   it's quite probable I don't understand how this works:

File "~/dist/src/matplotlib-git/matplotlib/build/lib.linux-i686-3.2/matplotlib/axes.py", 
line 2191, in ticklabel_format
     "This method only works with the ScalarFormatter.")

* I wanted some onmouseover() bubble annotation over specific markers but I
   gave up on this. Ideally I'd want to refer to the markers with a specific
   ID, give them different color style, and be able to add specific <title> or
   <text> elements where I want and manipulate them via javascript.

   Since I understand this is too much to ask from matplotlib I'd very much
   like the possibility to get the XML tree in some form *before* writing
   anything to disk. Does the SVG backend use the python xml.etree.ElementTree
   module? If only I could get the whole ElementTree, I would manipulate it as
   I'd like before writing to disk. What would you suggest to achieve the
   result I need?


I also had some difficulties with the website. For example when 
investigating various plotting utilities and checking their SVG output, I 
couldn't find anywhere the example from [1] rendered as SVG. The gallery 
is huge, but it is barely searchable (no text anywhere) so I still might 
have missed it. Secondly I'd appreciate a table of contents on top of the 
API pages, e.g. at http://matplotlib.sourceforge.net/api/pyplot_api.html

[1] http://matplotlib.sourceforge.net/examples/user_interfaces/svg_histogram.html


Finally, using more and more matplotlib I realised that some things are 
more complex than necessary. I'm talking specifically for when subplots or 
twin axes are involved. Then it is hard to keep a common legend (you have 
to keep track of the labels yourself). It is also hard to cycle the colors 
among the different axes (you have to keep track of the colors yourself). 
To have a common ylabel among the vertical subplots I just set the ylabel 
for the middle subplot, which seems like a hack. And also suptitle() seems 
weaker than title() (not bold, smaller font). Finally labels of yticks 
many times overlap each other at the border of adjascent subplots, so I 
have to manually compensate using set_major_locate() for sparser yticks.


Even though some things needed time-consuming hacks, matplotlib worked 
fine. Thanks for your work on this fantastic library!  And if you are 
curious you can see my automatic generated graphs (temporarily) at:

http://teras-ics.mooo.com:8003


thanks,
Dimitris


P.S. I sent this email (slightly changed) again a couple of months ago, 
but it got stuck in moderation. Thus I send it again now after 
subscribing, sorry if you get it twice.

[matplotlib-devel] Matplotlib Qt4Agg backend ignores 'resize_event'

[Stefan H. <shm...@gm...>]

Hello,

It appears that the Qt4Agg backend ignores any user defined 'resize_event'.
This program reproduces the issue (I am using the development version of
matplotlib from github):

import matplotlib
matplotlib.use('Qt4Agg')
import matplotlib.pyplot as plt

def say_hello(event):
    print "Hello"

fig = plt.figure()
fig.canvas.mpl_connect('resize_event', say_hello)
plt.show()

Resizing the figure does not result in "Hello" outputs, as it should.

The issue seems to be in lib/matplotlib/backends/backend_qt4.py, where
resizeEvent() looks like:

def resizeEvent( self, event ):
        if DEBUG: print('resize (%d x %d)' % (event.size().width(),
event.size().height()))
        w = event.size().width()
        h = event.size().height()
        if DEBUG: print("FigureCanvasQtAgg.resizeEvent(", w, ",", h, ")")
        dpival = self.figure.dpi
        winch = w/dpival
        hinch = h/dpival
        self.figure.set_size_inches( winch, hinch )
        self.draw()
        self.update()
        QtGui.QWidget.resizeEvent(self, event)
        
By comparison with the other surrounding event handlers, the callback to
FigureCanvasBase.resize_event() is manifestly missing. Indeed, adding

        FigureCanvasBase.resize_event(self)

at the end of resizeEvent() solves the problem.

Thanks,
Stefan

-- 
View this message in context: http://old.nabble.com/Matplotlib-Qt4Agg-backend-ignores-%27resize_event%27-tp34205981p34205981.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.