Hi matplotlib developers, we are developing a symbolic manipulation library in pure Python: http://code.google.com/p/sympy/ and we wanted to do 3D plotting. To make a long story short, here is a tutorial for our 3D plotting stuff: http://code.google.com/p/sympy/wiki/PlottingModule here is a reasoning behind all of this: http://code.google.com/p/sympy/wiki/PlottingReport especially this: http://straightupcoding.blogspot.com/2007/05/case-for-dropping-matplotlib.html We should have gotten involved more in matplotlib development earlier, but at least now. I think there should be just one 3D plotting library in Python and imho matplotlib should do it. However, we need: * it should be pure python * fast and interactive 3D stuff * needs to work out of the box on linux, mac os x, windows (without compilation) you can read all details above, but we simply use pyglet (http://pyglet.org/), that is like pygame, but better (pure python, works out of the box on all platforms etc). Are you interested in getting our 3D stuff into matplotlib? If yes, is there a way to make matplotlib pure python? Looking at matplotlib sources, the only things done in C++ are agg backend, and then the src/* directory, which I am not sure what exactly it's doing, but I don't see a reason why the kernel of matplotlib cannot be in pure Python (calling python gtk etc.). Optionally, there can be the C++ modules. If such a division is possible, then we could just include matplotlib in sympy sources, the license of matplotlib seems quite permissive: http://matplotlib.sourceforge.net/license.html so it should allow this (sympy and pyglet is BSD). In distributions, like Debian, sympy will just depend on matplotlib in debian. But the sympy tarball should be self-contained. The sympy plotting is quite nice, especially that you just download the tarball and it works (even on windows, or macosx) without compilation, however it's missing a lot of features that matplotlib has, so the best thing to do is to integrate it in matplotlib. Another cool stuff in matplotlib is the pure python latex renderer (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for more info: http://code.google.com/p/sympy/issues/detail?id=506 we want to use it in our preview capability (currently only in our hg repo): $ hg clone http://hg.sympy.org/sympy/ $ cd sympy $ bin/isympy [...] In [1]: from sympy.abc import * In [2]: pngview(Integral(exp(-(tau-mu)**2/2/sigma**2), (tau, -oo, oo))/ ...: sigma/sqrt(2*pi)) And a window will popup (using pyglet) showing a nice latex printed expression. Currently, you need to have latex installed (and python-pexpect) for it to be working. (if you use sympy hg right now, you need python-pexpect, but we'll fix this before we release soon: http://code.google.com/p/sympy/issues/detail?id=520, any sympy tarball only needs pure Python 2.4 or newer and it will just work, otherwise it's a bug) So it'd be cool to you your pure python reimplementation of the tex engine. Maybe let's create a new (standalone) project just for this feature? I am sure it will benefit to a lot of people. And sympy and matplotlib will just include it in the sources. If you have any other ideas regarding these issues, we are interested. Looking for collaboration, Ondrej
Resending, the first try doesn't seem to make it to the list. ---------- Forwarded message ---------- From: Ondrej Certik <on...@ce...> Date: Dec 30, 2007 7:33 PM Subject: merging sympy plotting stuff with matplotlib To: mat...@li... Hi matplotlib developers, we are developing a symbolic manipulation library in pure Python: http://code.google.com/p/sympy/ and we wanted to do 3D plotting. To make a long story short, here is a tutorial for our 3D plotting stuff: http://code.google.com/p/sympy/wiki/PlottingModule here is a reasoning behind all of this: http://code.google.com/p/sympy/wiki/PlottingReport especially this: http://straightupcoding.blogspot.com/2007/05/case-for-dropping-matplotlib.html We should have gotten involved more in matplotlib development earlier, but at least now. I think there should be just one 3D plotting library in Python and imho matplotlib should do it. However, we need: * it should be pure python * fast and interactive 3D stuff * needs to work out of the box on linux, mac os x, windows (without compilation) you can read all details above, but we simply use pyglet (http://pyglet.org/), that is like pygame, but better (pure python, works out of the box on all platforms etc). Are you interested in getting our 3D stuff into matplotlib? If yes, is there a way to make matplotlib pure python? Looking at matplotlib sources, the only things done in C++ are agg backend, and then the src/* directory, which I am not sure what exactly it's doing, but I don't see a reason why the kernel of matplotlib cannot be in pure Python (calling python gtk etc.). Optionally, there can be the C++ modules. If such a division is possible, then we could just include matplotlib in sympy sources, the license of matplotlib seems quite permissive: http://matplotlib.sourceforge.net/license.html so it should allow this (sympy and pyglet is BSD). In distributions, like Debian, sympy will just depend on matplotlib in debian. But the sympy tarball should be self-contained. The sympy plotting is quite nice, especially that you just download the tarball and it works (even on windows, or macosx) without compilation, however it's missing a lot of features that matplotlib has, so the best thing to do is to integrate it in matplotlib. Another cool stuff in matplotlib is the pure python latex renderer (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for more info: http://code.google.com/p/sympy/issues/detail?id=506 we want to use it in our preview capability (currently only in our hg repo): $ hg clone http://hg.sympy.org/sympy/ $ cd sympy $ bin/isympy [...] In [1]: from sympy.abc import * In [2]: pngview(Integral(exp(-(tau-mu)**2/2/sigma**2), (tau, -oo, oo))/ ...: sigma/sqrt(2*pi)) And a window will popup (using pyglet) showing a nice latex printed expression. Currently, you need to have latex installed (and python-pexpect) for it to be working. (if you use sympy hg right now, you need python-pexpect, but we'll fix this before we release soon: http://code.google.com/p/sympy/issues/detail?id=520, any sympy tarball only needs pure Python 2.4 or newer and it will just work, otherwise it's a bug) So it'd be cool to you your pure python reimplementation of the tex engine. Maybe let's create a new (standalone) project just for this feature? I am sure it will benefit to a lot of people. And sympy and matplotlib will just include it in the sources. If you have any other ideas regarding these issues, we are interested. Looking for collaboration, Ondrej
On Mon, Dec 31, 2007 at 12:40:26AM +0100, Ondrej Certik wrote: > I think there should be just one 3D plotting > library in Python and imho matplotlib should do it. However, we need: > * it should be pure python > * fast and interactive 3D stuff > * needs to work out of the box on linux, mac os x, windows (without compilation) A long time ago I took a close look at adding powerful 3D features in gnuplot, namely povray exporting, but I found out that some core work was needed. What I think I learnt from this experience was that the core plotting engine couldn't share much code between the 2D and the 3D. I drew the conclusion that the 2D and 3D plotting packages should be different, eventhough, it might be interesting to connect together them as well as possible. I also think that code reuse is very important, and that I don't want to write a rendered. This is why I set up on the endeaviour of modifying Mayavi2 to make it pylab-like. Prabhu has opened to way to the use of Mayavi2 solely as a library, and together we have worked on an API with a familiar syntax, and a light UI. There has been much progress, as I illustrate on a blogpost: http://gael-varoquaux.info/blog/?p=3 This does not answer you problem, as two of you requirements are not satisfied (namely because of the use of VTK). I have the feeling that you are looking for something simpler than what we are building. However this does not mean we cannot work together to try to make the APIs as similar as possible, and to make it easy to replace one library with another. By the way, mayavi2's requirement list is heavy, we have been told this more than once, but I consider some dependencies (namely traits and friends) to be core technology that many other projects would gain to use, moreover they are easy to build (althought packaging with eggs tends to confuse people). On the contrary, I fully admit VTK is a heavy dependency and that it would be an interesting project for an alternate library to provide part of the features without this dependency. I just got a message from Michael McKerns saying that the DANSE project are also working on a pylab-like API to VTK. We are planning to try and coordinnate our APIs. OK, I really must go to sleep now. Gaël
Hi Michael, John and Gael, sorry for the later reply (holidays and stuff...) On Jan 1, 2008 4:51 AM, Michael Droettboom <md...@st...> wrote: > I'm off with family for the holidays, so my response will have to be somewhat > brief. > > I'm excited about the ideas you bring up... I first heard about sympy at SciPy > and was very impressed. Let's try to collaborate in any way possible. I know > that "3D in matplotlib" already has some history of which I'm not aware, so I'll > leave that for others to comment on. > > As for the C++ dependencies, Agg is a pretty strong one. Yes, it is possible to > do rendering with Gtk or Wx alone, but it's not very pretty (no-aa). Gtk/Cairo is > a good high-quality combination, but it (at least currently) leaves out all the > other GUI frameworks, and is not BSD-like licensed. The other important > C/C++ requirement is matplotlib's interface to freetype (FT2Font). That would > be really painful to reimplement in pure Python -- freetype is a complex and > mature piece of software. In the trunk, there is a required framework for > transformations, and in the "transforms branch" there is a framework for > polycurve manipulations, both of which are required to do any plotting. Those > would have a major performance penalty going to Python, and even > notwithstanding, are non-trivial bits of code to reimplement. Beyond that, there > are utilities for contours and images etc., which are reasonably optional but > people use all the time. In short, there's a not of C/C++ in the core of > matplotlib -- maybe the time would be better spent resolving any build issues > that make portability difficult...? I'm not sure it's realistic to expect matplotlib to > be pure Python at this point without losing a lot of features, but I agree it would > be nice... I'll reply to this below. > As for the mathtext Python math rendering engine, it isn't *really* pure Python. > It relies on matplotlib's interface to Freetype. Ideally, it would be nice to have a > general-purpose Python interface to freetype (I know the PyCairo folks are > wanting such a thing), and then the mathtext engine could use that. > Unfortunately, the existing freetype wrapper in matplotlib is very incomplete > and pretty tied to matplotlib-specific ways of doing things. IMHO, you wouldn't > really gain much by releasing FT2Font as a separate project unless it were > generalized. I've sort of gone into a holding pattern, hoping someone else will > release a Python freetype wrapper that matplotlib could use... Alternatively, the > dependency on freetype could be removed by extracting and hardcoding all the > font metrics from the math fonts into Python dictionaries etc. -- but then of > course it would only work with a fixed set of fonts. This is what jsMath, (a > pure-Javascript math rendering engine) does, for instance. > > With the exception of that issue, removing the mathtext engine from matplotlib > should be possible, and I think it's a great idea. There are some matplotlib- > specific bits mixed in there, but they should be reasonably straightforward to > factor out. It already has support for rendering math to an in-memory image > bitmap, which has been used for displaying math on GUI widgets, for example. > > Anyway -- cool ideas. Let's keep up the discussion. > > Cheers, > Mike > On Jan 1, 2008 3:51 PM, John Hunter <jd...@gm...> wrote: > On Dec 30, 2007 12:33 PM, Ondrej Certik <on...@ce...> wrote: > > > We should have gotten involved more in matplotlib development earlier, > > but at least now. I think there should be just one 3D plotting > > library in Python and imho matplotlib should do it. However, we need: > > Hi Ondrej, > > Sorry for the delay getting back to you. I've been on holiday so have > only limited email access. > > > * it should be pure python > > * fast and interactive 3D stuff > > * needs to work out of the box on linux, mac os x, windows (without compilation) > > We have long wanted limited 3D capability in matplotlib, and as you > know we have some functionality in the axes3d classes but it has > proven to be extremely slow, and somewhat buggy, and the original > author has moved on to other things so it is mostly unsupported. We > would be very excited if there was some way to incorporate your work > using pyglet, which is very nice. > > matplotlib started out life as pure python, and for several release > cycles remained that way. A that time, there were two backends, GTK > and PS, so there is no reason in principle that matplotlib needs to > have extension code. Over time, we have evolved a considerable amount > of extension code, which Michael outlined for you, but it generally > falls into two classes: > > * access 3rd party C/C++ (Agg, freetype and libpng) > > * make matplotlib go faster (image, transforms, other helpers) > > A big chunk of extension code was removed in Michael's recent > refactoring of transforms, and it is possible and desirable to remove > more. Eg, we should be able to replace ft2font with a ctypes wrapper, > though I have never experimented with this. > > While I think reducing the amount of extension code is useful and > desirable, the complete eradication of it is unlikely, and would > result in a matplotlib with limited functionality. Michael > mentioned a few of these areas, but contouring and image support make > heavy use of extension code that would be difficult to do in python. > Also, we depend very heavily numpy, so even if matplotlib were pure > python, it would depend on numpy which is not. And that dependency is > at the core of matplotlib. > > I tend to agree with Michael: our effort would be better spent > identifying the areas that make compilation problematic than trying to > remove all extension code. For the most part, these difficulties > arise from depending on 3rd party C/C+ code at compile time (eg a GUI > toolkit or libpng or freetype). I would love to find a way to remove > all these compile time dependencies. All right, so to recapitulate. From the technical point of view, the C/C++ dependency is * numpy (this one will be hard to remove) * image extension code (this could be maybe done using pyglet?) * freetype (this could be rewritten using ctypes) * libpng (this could be optional) * Agg (this could be optional) I understand, that from the matplotlib point of view, C/C++ depenency is fine. But in sympy, we don't want to use C/C++ by default. SymPy is mainly symbolic manipulation library. Everything else is nice, if it can be done in pure python, if it cannot, we'll not include it by default Of course, users can use matplotlib externally and that's fine. But still being able to do some graphing from sympy is very cool, because it's easy. Ideal solution imho is this: * the kernel of matplotlib is pure python, i.e. we can include it in sympy * all the modules could be included by default in the matplotlib distribution, but not in sympy Compiling really sucks. I mean, I am not against C, we will probably include an optional C module too for speeding up sympy, but not by default. pyglet shows, that it is possible to do nice and fast 3D plots in pure python, so we'll have that in sympy. But I would like to have solid 2D plotting too, and I don't want to reinvent the wheel and split communities. We actually already did that, by designing our own 3D plotting stuff, but that was mainly to show, that this indeed is the way to go. So, at least, we can try to include it in matplotlib. Unfortunately, I don't have time for that, but I think you already have some ideas where and how to do it. And I can help with any questions you might have. But we'll try to help if it is possible to separate at least something in pure python, so that we can use it. > > Another cool stuff in matplotlib is the pure python latex renderer > > (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for > > more info: > > Yes, the mathtext support in matplotlib is very nice, and Michael > deserves the credit for taking from a package that > works but has warts, to an extremely nice math layout engine using the > Knuth algorithms. I'm sure others would like to use it without having > to pull in all of matplotlib. With a ctypes freetype wrapper, it > should be possible to build a free-standing mathtext. And this is really cool. I would like to have that. :) We'll try to help with that one. On Jan 4, 2008 3:48 AM, Gael Varoquaux <gae...@no...> wrote: > On Mon, Dec 31, 2007 at 12:40:26AM +0100, Ondrej Certik wrote: > > I think there should be just one 3D plotting > > library in Python and imho matplotlib should do it. However, we need: > > > * it should be pure python > > * fast and interactive 3D stuff > > * needs to work out of the box on linux, mac os x, windows (without compilation) > > A long time ago I took a close look at adding powerful 3D features in > gnuplot, namely povray exporting, but I found out that some core work was > needed. > > What I think I learnt from this experience was that the core plotting > engine couldn't share much code between the 2D and the 3D. I drew the > conclusion that the 2D and 3D plotting packages should be different, > eventhough, it might be interesting to connect together them as well as > possible. The 3D engine and everything is already done in SymPy. Now the question is how and if to connect this with matplotlib. I think all of us want that. And also the other way round - get the 2D plotting from matplotlib and use it in sympy. > I also think that code reuse is very important, and that I don't want to > write a rendered. That is already done. > This is why I set up on the endeaviour of modifying Mayavi2 to make it > pylab-like. Prabhu has opened to way to the use of Mayavi2 solely as a > library, and together we have worked on an API with a familiar syntax, > and a light UI. There has been much progress, as I illustrate on a > blogpost: http://gael-varoquaux.info/blog/?p=3 Yes, exactly. > This does not answer you problem, as two of you requirements are not > satisfied (namely because of the use of VTK). I have the feeling that you > are looking for something simpler than what we are building. However this > does not mean we cannot work together to try to make the APIs as similar > as possible, and to make it easy to replace one library with another. > > By the way, mayavi2's requirement list is heavy, we have been told this > more than once, but I consider some dependencies (namely traits and > friends) to be core technology that many other projects would gain to > use, moreover they are easy to build (althought packaging with eggs tends > to confuse people). On the contrary, I fully admit VTK is a heavy > dependency and that it would be an interesting project for an alternate > library to provide part of the features without this dependency. > > > I just got a message from Michael McKerns saying that the DANSE project > are also working on a pylab-like API to VTK. We are planning to try and > coordinnate our APIs. > > OK, I really must go to sleep now. Right. Definitely at least the API should be the same. But I still would like to use matplotlib, because many people use it and are familiar with it. Sage uses it too. As to the speed of python, I think, at least as far as sympy is concerned, it's enough, if things are done cleverly. See my latest post for that: http://ondrejcertik.blogspot.com/2008/01/sympysympycore-pure-python-up-to-5x.html And if 3D things can be done in pure python, 2D things can be too. And if something can be done in pure python, it's fast enough, then it should be done in python, rather than C. That's my logic. :) Ondrej
Ondrej Certik wrote: > * freetype (this could be rewritten using ctypes) I see that pyglet already has a freetype wrapper using ctypes -- it would be interesting to see if that could be used as a starting point. That could be used as a starting point. (Of course, ctypes is an external dependency before Python-2.5, which adds a dependency to matplotlib). I generally don't like ctypes-based wrappers since changes in the dependency can mean segfaults at runtime. I'm having a problem getting pyglet to work on my particular version of OpenGL, for instance. But perhaps freetype is stable enough for that not to be a problem. > * Agg (this could be optional) On the transforms branch, Agg is used for bezier curve realisation, whether the Agg renderer is being used or not. This is used for things like hit-testing and range-setting of path collections etc. This was not fast enough in my earlier numpy-based implementation, since to take advantage of numpy, you generally have to allocate lots of memory to store the results in. In this particular case, each value can be immediately thrown away, so all that extra work was unnecessary. > Compiling really sucks. Agreed. But there is a spectrum of suckage here. It also sucks to be unable to check that a call to some library that you don't provide (freetype) will succeed. >>> Another cool stuff in matplotlib is the pure python latex renderer >>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for >>> more info: >> Yes, the mathtext support in matplotlib is very nice, and Michael >> deserves the credit for taking from a package that >> works but has warts, to an extremely nice math layout engine using the >> Knuth algorithms. I'm sure others would like to use it without having >> to pull in all of matplotlib. With a ctypes freetype wrapper, it >> should be possible to build a free-standing mathtext. > > And this is really cool. I would like to have that. :) > > We'll try to help with that one. Great! I'll start by looking at pyglet's freetype wrapper and see how far I get. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Jan 4, 2008 7:41 PM, Michael Droettboom <md...@st...> wrote: > Ondrej Certik wrote: > > * freetype (this could be rewritten using ctypes) > > I see that pyglet already has a freetype wrapper using ctypes -- it > would be interesting to see if that could be used as a starting point. > That could be used as a starting point. (Of course, ctypes is an > external dependency before Python-2.5, which adds a dependency to > matplotlib). That is correct. I forgot about that. We do support python2.4 and it's true that in order for plotting to work, you need to install python-ctypes. But python2.4 will hopefully get old soon, in favor of python2.5. > I generally don't like ctypes-based wrappers since changes in the > dependency can mean segfaults at runtime. I'm having a problem getting > pyglet to work on my particular version of OpenGL, for instance. But > perhaps freetype is stable enough for that not to be a problem. Could you please report it to http://groups.google.com/group/pyglet-users ? Alex (the author of pyglet) is really responsive. My own experience is that it works out of the box. > > * Agg (this could be optional) > > On the transforms branch, Agg is used for bezier curve realisation, > whether the Agg renderer is being used or not. This is used for things > like hit-testing and range-setting of path collections etc. This was > not fast enough in my earlier numpy-based implementation, since to take > advantage of numpy, you generally have to allocate lots of memory to > store the results in. In this particular case, each value can be > immediately thrown away, so all that extra work was unnecessary. So it's needed for path collections - what is that? When I want to do regular plots, like plotting some set of points, is that needed too? If not, it should be optional imho. > > Compiling really sucks. > > Agreed. But there is a spectrum of suckage here. It also sucks to be > unable to check that a call to some library that you don't provide > (freetype) will succeed. That sucks too. But I think there are mechanisms to check the exact version of the library, aren't there? > >>> Another cool stuff in matplotlib is the pure python latex renderer > >>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for > >>> more info: > >> Yes, the mathtext support in matplotlib is very nice, and Michael > >> deserves the credit for taking from a package that > >> works but has warts, to an extremely nice math layout engine using the > >> Knuth algorithms. I'm sure others would like to use it without having > >> to pull in all of matplotlib. With a ctypes freetype wrapper, it > >> should be possible to build a free-standing mathtext. > > > > And this is really cool. I would like to have that. :) > > > > We'll try to help with that one. > > Great! I'll start by looking at pyglet's freetype wrapper and see how > far I get. Awesome. Please ask on the list above, as I said, Alex is quite guru, so he will answer any technical questions. Ondrej
On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote: > > > * Agg (this could be optional) > > > > On the transforms branch, Agg is used for bezier curve realisation, > > whether the Agg renderer is being used or not. This is used for things > > like hit-testing and range-setting of path collections etc. This was > > not fast enough in my earlier numpy-based implementation, since to take > > advantage of numpy, you generally have to allocate lots of memory to > > store the results in. In this particular case, each value can be > > immediately thrown away, so all that extra work was unnecessary. > > So it's needed for path collections - what is that? When I want to do > regular plots, > like plotting some set of points, is that needed too? If not, it > should be optional imho. It's probably worth mentioning that one of the reasons John chose Agg is because of image *quality* concerns. If I'm not mistaken (John and A. Straw will correct me as needed), the OpenGL anti-aliasing quality is positively horrible when you compare it to the quality of Agg. Keep in mind that OpenGL is typically focused on keeping high frame-rates for moving images, so pixel-perfect antialiasing is much less of a concern for them, since your eye is a lot less likely to notice such fine details (as long as there is *some* antialiasing). For a static image, you tend to be a lot pickier, and Agg goes to great lengths to ensure the best possible antialiasing quality. This is part of the reason why normal television, at abysmally low resolutions is still acceptable for viewing, while nobody would consider a 400-line-image an acceptable photograph for most uses. You 'stare' at the moving image only for 1/30 s or so, while you look at the static one for much longer. Just look at some of their examples to get an idea of what I'm talking about: http://www.antigrain.com/screenshots/index.html I've never seen any opengl-based antialiasing be of that quality. But there may be ways of achieving the same thing in OpenGL, I don't know (and to do so efficiently and portably, without requiring specific video cards). The other issue I recall is that the quality of openGL antialiasing is highly dependent on the video card and/or driver. While that may be OK for gamers, it's completely unacceptable IMO for scientific publication. > > > Compiling really sucks. Keep in mind that while python+cleverness can get you a lot of speed, there are operations that are *inescapably* slow in python's fully dynamic model today (without JIT-type tricks a la psyco that avoid dynamic dispatch in loops). Running a tight loop over a million elements of anything to do some repetitive operation will incur in Python's runtime check costs on every pass of the loop. In a plotting library, this type of computation is very frequent, and while some of it can be rolled into numpy-type array operations, that's not always possible. There's simply no way out (today) from compiled code for certain things in python, I'm afraid. Keep in mind that there are still people who regularly complain about MPL being *too slow* for their purposes, which involve interactive data exploration of enormous datasets. I'm sure that loss of speed would not be considered a desirable feature for a new MPL release by many :) I'm certainly hoping you guys can find some mechanism to join forces on this front, which I would absolutely love to see. But I just want to provide a bit of context as to why MPL uses extensions like Agg and relies on compiled code, which is I think a fairly critical need of the project. Having said all this, I'd be thrilled to be proven 100% wrong in all of the above, and to see a pure-python MPL that is as fast as today's and maintains the image quality we have today. One approach that has been thrown around in the past was to have an opengl based render while working interactively, that would force a re-render of the same entire scene via Agg for image saving. I don't know enough about the MPL internals to say how feasible this would be. Cheers, f
On Dec 30, 2007 12:33 PM, Ondrej Certik <on...@ce...> wrote: > We should have gotten involved more in matplotlib development earlier, > but at least now. I think there should be just one 3D plotting > library in Python and imho matplotlib should do it. However, we need: Hi Ondrej, Sorry for the delay getting back to you. I've been on holiday so have only limited email access. > * it should be pure python > * fast and interactive 3D stuff > * needs to work out of the box on linux, mac os x, windows (without compilation) We have long wanted limited 3D capability in matplotlib, and as you know we have some functionality in the axes3d classes but it has proven to be extremely slow, and somewhat buggy, and the original author has moved on to other things so it is mostly unsupported. We would be very excited if there was some way to incorporate your work using pyglet, which is very nice. matplotlib started out life as pure python, and for several release cycles remained that way. A that time, there were two backends, GTK and PS, so there is no reason in principle that matplotlib needs to have extension code. Over time, we have evolved a considerable amount of extension code, which Michael outlined for you, but it generally falls into two classes: * access 3rd party C/C++ (Agg, freetype and libpng) * make matplotlib go faster (image, transforms, other helpers) A big chunk of extension code was removed in Michael's recent refactoring of transforms, and it is possible and desirable to remove more. Eg, we should be able to replace ft2font with a ctypes wrapper, though I have never experimented with this. While I think reducing the amount of extension code is useful and desirable, the complete eradication of it is unlikely, and would result in a matplotlib with limited functionality. Michael mentioned a few of these areas, but contouring and image support make heavy use of extension code that would be difficult to do in python. Also, we depend very heavily numpy, so even if matplotlib were pure python, it would depend on numpy which is not. And that dependency is at the core of matplotlib. I tend to agree with Michael: our effort would be better spent identifying the areas that make compilation problematic than trying to remove all extension code. For the most part, these difficulties arise from depending on 3rd party C/C+ code at compile time (eg a GUI toolkit or libpng or freetype). I would love to find a way to remove all these compile time dependencies. > Another cool stuff in matplotlib is the pure python latex renderer > (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for > more info: Yes, the mathtext support in matplotlib is very nice, and Michael deserves the credit for taking from a package that works but has warts, to an extremely nice math layout engine using the Knuth algorithms. I'm sure others would like to use it without having to pull in all of matplotlib. With a ctypes freetype wrapper, it should be possible to build a free-standing mathtext. JDH
On Jan 4, 2008 8:19 PM, Fernando Perez <fpe...@gm...> wrote: > On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote: > > > > > * Agg (this could be optional) > > > > > > On the transforms branch, Agg is used for bezier curve realisation, > > > whether the Agg renderer is being used or not. This is used for things > > > like hit-testing and range-setting of path collections etc. This was > > > not fast enough in my earlier numpy-based implementation, since to take > > > advantage of numpy, you generally have to allocate lots of memory to > > > store the results in. In this particular case, each value can be > > > immediately thrown away, so all that extra work was unnecessary. > > > > So it's needed for path collections - what is that? When I want to do > > regular plots, > > like plotting some set of points, is that needed too? If not, it > > should be optional imho. > > It's probably worth mentioning that one of the reasons John chose Agg > is because of image *quality* concerns. If I'm not mistaken (John and > A. Straw will correct me as needed), the OpenGL anti-aliasing quality > is positively horrible when you compare it to the quality of Agg. > Keep in mind that OpenGL is typically focused on keeping high > frame-rates for moving images, so pixel-perfect antialiasing is much > less of a concern for them, since your eye is a lot less likely to > notice such fine details (as long as there is *some* antialiasing). > For a static image, you tend to be a lot pickier, and Agg goes to > great lengths to ensure the best possible antialiasing quality. This > is part of the reason why normal television, at abysmally low > resolutions is still acceptable for viewing, while nobody would > consider a 400-line-image an acceptable photograph for most uses. You > 'stare' at the moving image only for 1/30 s or so, while you look at > the static one for much longer. > > Just look at some of their examples to get an idea of what I'm talking about: > > http://www.antigrain.com/screenshots/index.html > > I've never seen any opengl-based antialiasing be of that quality. But > there may be ways of achieving the same thing in OpenGL, I don't know > (and to do so efficiently and portably, without requiring specific > video cards). > > The other issue I recall is that the quality of openGL antialiasing is > highly dependent on the video card and/or driver. While that may be > OK for gamers, it's completely unacceptable IMO for scientific > publication. > > > > > Compiling really sucks. > > Keep in mind that while python+cleverness can get you a lot of speed, > there are operations that are *inescapably* slow in python's fully > dynamic model today (without JIT-type tricks a la psyco that avoid > dynamic dispatch in loops). Running a tight loop over a million > elements of anything to do some repetitive operation will incur in > Python's runtime check costs on every pass of the loop. In a plotting > library, this type of computation is very frequent, and while some of > it can be rolled into numpy-type array operations, that's not always > possible. There's simply no way out (today) from compiled code for > certain things in python, I'm afraid. Keep in mind that there are > still people who regularly complain about MPL being *too slow* for > their purposes, which involve interactive data exploration of enormous > datasets. I'm sure that loss of speed would not be considered a > desirable feature for a new MPL release by many :) > > I'm certainly hoping you guys can find some mechanism to join forces > on this front, which I would absolutely love to see. But I just want > to provide a bit of context as to why MPL uses extensions like Agg and > relies on compiled code, which is I think a fairly critical need of > the project. > > Having said all this, I'd be thrilled to be proven 100% wrong in all > of the above, and to see a pure-python MPL that is as fast as today's > and maintains the image quality we have today. > > One approach that has been thrown around in the past was to have an > opengl based render while working interactively, that would force a > re-render of the same entire scene via Agg for image saving. I don't > know enough about the MPL internals to say how feasible this would be. Hi Fernando! what you said are valid points for matplotlib using Agg as a backend. And as I said, the default matplotlib installation should include it, no doubt about that. On the other hand, I (and I think many other users) only need the super quality only when saving the final plot. Of course, if it's worth the pain, I can install the agg backend and have the quality all the time, but many users will sacrifice the quality, if they can get at least some plot. If it was just me, I use Debian, so for me using any C compiled code is zero pain. But, the majority of users of sympy, are probably windows users. (At least there are more downloads of the windows installer, than the mulitplatform tarball). And I am not sure compiling anything on windows is a pleasant experience (honestly I think forcing a user of sympy compiling something on windows is a show stopper). Ondrej
[ oops, this was meant to be on-list] Hey Ondrej, On Jan 4, 2008 12:36 PM, Ondrej Certik <on...@ce...> wrote: > Hi Fernando! > > what you said are valid points for matplotlib using Agg as a backend. > And as I said, > the default matplotlib installation should include it, no doubt about that. > > On the other hand, I (and I think many other users) only need the super quality > only when saving the final plot. Of course, if it's worth the pain, I > can install the agg > backend and have the quality all the time, but many users will > sacrifice the quality, > if they can get at least some plot. > > If it was just me, I use Debian, so for me using any C compiled code > is zero pain. But, > the majority of users of sympy, are probably windows users. (At least there are > more downloads of the windows installer, than the mulitplatform tarball). And > I am not sure compiling anything on windows is a pleasant experience > (honestly I > think forcing a user of sympy compiling something on windows is a show stopper). Indeed, compiled code in a project basically forces you to have a windows developer in the team who can build the binary installers. These days with vmware/qemu it's not the end of the world (it can be done in a normal computer running linux/osx) but it's still a pain for most of us, no doubt about it. Again, I was just trying to provide context. From where I stand, I'm cheering as hard as I can for you guys to succeed. Cheers, f
On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote: > On Jan 4, 2008 8:19 PM, Fernando Perez <fpe...@gm...> wrote: > > On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote: > > > > > * Agg (this could be optional) > > > > > > > > On the transforms branch, Agg is used for bezier curve realisation, > > > > whether the Agg renderer is being used or not. This is used for > > > > things like hit-testing and range-setting of path collections etc. > > > > This was not fast enough in my earlier numpy-based implementation, > > > > since to take advantage of numpy, you generally have to allocate lots > > > > of memory to store the results in. In this particular case, each > > > > value can be immediately thrown away, so all that extra work was > > > > unnecessary. > > > > > > So it's needed for path collections - what is that? When I want to do > > > regular plots, > > > like plotting some set of points, is that needed too? If not, it > > > should be optional imho. > > > > It's probably worth mentioning that one of the reasons John chose Agg > > is because of image *quality* concerns. If I'm not mistaken (John and > > A. Straw will correct me as needed), the OpenGL anti-aliasing quality > > is positively horrible when you compare it to the quality of Agg. > > Keep in mind that OpenGL is typically focused on keeping high > > frame-rates for moving images, so pixel-perfect antialiasing is much > > less of a concern for them, since your eye is a lot less likely to > > notice such fine details (as long as there is *some* antialiasing). > > For a static image, you tend to be a lot pickier, and Agg goes to > > great lengths to ensure the best possible antialiasing quality. This > > is part of the reason why normal television, at abysmally low > > resolutions is still acceptable for viewing, while nobody would > > consider a 400-line-image an acceptable photograph for most uses. You > > 'stare' at the moving image only for 1/30 s or so, while you look at > > the static one for much longer. > > > > Just look at some of their examples to get an idea of what I'm talking > > about: > > > > http://www.antigrain.com/screenshots/index.html > > > > I've never seen any opengl-based antialiasing be of that quality. But > > there may be ways of achieving the same thing in OpenGL, I don't know > > (and to do so efficiently and portably, without requiring specific > > video cards). > > > > The other issue I recall is that the quality of openGL antialiasing is > > highly dependent on the video card and/or driver. While that may be > > OK for gamers, it's completely unacceptable IMO for scientific > > publication. > > > > > > > Compiling really sucks. > > > > Keep in mind that while python+cleverness can get you a lot of speed, > > there are operations that are *inescapably* slow in python's fully > > dynamic model today (without JIT-type tricks a la psyco that avoid > > dynamic dispatch in loops). Running a tight loop over a million > > elements of anything to do some repetitive operation will incur in > > Python's runtime check costs on every pass of the loop. In a plotting > > library, this type of computation is very frequent, and while some of > > it can be rolled into numpy-type array operations, that's not always > > possible. There's simply no way out (today) from compiled code for > > certain things in python, I'm afraid. Keep in mind that there are > > still people who regularly complain about MPL being *too slow* for > > their purposes, which involve interactive data exploration of enormous > > datasets. I'm sure that loss of speed would not be considered a > > desirable feature for a new MPL release by many :) > > > > I'm certainly hoping you guys can find some mechanism to join forces > > on this front, which I would absolutely love to see. But I just want > > to provide a bit of context as to why MPL uses extensions like Agg and > > relies on compiled code, which is I think a fairly critical need of > > the project. > > > > Having said all this, I'd be thrilled to be proven 100% wrong in all > > of the above, and to see a pure-python MPL that is as fast as today's > > and maintains the image quality we have today. > > > > One approach that has been thrown around in the past was to have an > > opengl based render while working interactively, that would force a > > re-render of the same entire scene via Agg for image saving. I don't > > know enough about the MPL internals to say how feasible this would be. > > Hi Fernando! > > what you said are valid points for matplotlib using Agg as a backend. > And as I said, > the default matplotlib installation should include it, no doubt about that. > > On the other hand, I (and I think many other users) only need the super > quality only when saving the final plot. Of course, if it's worth the pain, > I can install the agg > backend and have the quality all the time, but many users will > sacrifice the quality, > if they can get at least some plot. > > If it was just me, I use Debian, so for me using any C compiled code > is zero pain. But, > the majority of users of sympy, are probably windows users. (At least there > are more downloads of the windows installer, than the mulitplatform > tarball). And I am not sure compiling anything on windows is a pleasant > experience (honestly I > think forcing a user of sympy compiling something on windows is a show > stopper). Why would your users have to compile anything on windows? Matplotlib's windows users just run the installer, the compilation has already been done. Am I missing something? Darren
On Jan 4, 2008 8:44 PM, Darren Dale <dar...@co...> wrote: > > On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote: > > On Jan 4, 2008 8:19 PM, Fernando Perez <fpe...@gm...> wrote: > > > On Jan 4, 2008 11:55 AM, Ondrej Certik <on...@ce...> wrote: > > > > > > * Agg (this could be optional) > > > > > > > > > > On the transforms branch, Agg is used for bezier curve realisation, > > > > > whether the Agg renderer is being used or not. This is used for > > > > > things like hit-testing and range-setting of path collections etc. > > > > > This was not fast enough in my earlier numpy-based implementation, > > > > > since to take advantage of numpy, you generally have to allocate lots > > > > > of memory to store the results in. In this particular case, each > > > > > value can be immediately thrown away, so all that extra work was > > > > > unnecessary. > > > > > > > > So it's needed for path collections - what is that? When I want to do > > > > regular plots, > > > > like plotting some set of points, is that needed too? If not, it > > > > should be optional imho. > > > > > > It's probably worth mentioning that one of the reasons John chose Agg > > > is because of image *quality* concerns. If I'm not mistaken (John and > > > A. Straw will correct me as needed), the OpenGL anti-aliasing quality > > > is positively horrible when you compare it to the quality of Agg. > > > Keep in mind that OpenGL is typically focused on keeping high > > > frame-rates for moving images, so pixel-perfect antialiasing is much > > > less of a concern for them, since your eye is a lot less likely to > > > notice such fine details (as long as there is *some* antialiasing). > > > For a static image, you tend to be a lot pickier, and Agg goes to > > > great lengths to ensure the best possible antialiasing quality. This > > > is part of the reason why normal television, at abysmally low > > > resolutions is still acceptable for viewing, while nobody would > > > consider a 400-line-image an acceptable photograph for most uses. You > > > 'stare' at the moving image only for 1/30 s or so, while you look at > > > the static one for much longer. > > > > > > Just look at some of their examples to get an idea of what I'm talking > > > about: > > > > > > http://www.antigrain.com/screenshots/index.html > > > > > > I've never seen any opengl-based antialiasing be of that quality. But > > > there may be ways of achieving the same thing in OpenGL, I don't know > > > (and to do so efficiently and portably, without requiring specific > > > video cards). > > > > > > The other issue I recall is that the quality of openGL antialiasing is > > > highly dependent on the video card and/or driver. While that may be > > > OK for gamers, it's completely unacceptable IMO for scientific > > > publication. > > > > > > > > > Compiling really sucks. > > > > > > Keep in mind that while python+cleverness can get you a lot of speed, > > > there are operations that are *inescapably* slow in python's fully > > > dynamic model today (without JIT-type tricks a la psyco that avoid > > > dynamic dispatch in loops). Running a tight loop over a million > > > elements of anything to do some repetitive operation will incur in > > > Python's runtime check costs on every pass of the loop. In a plotting > > > library, this type of computation is very frequent, and while some of > > > it can be rolled into numpy-type array operations, that's not always > > > possible. There's simply no way out (today) from compiled code for > > > certain things in python, I'm afraid. Keep in mind that there are > > > still people who regularly complain about MPL being *too slow* for > > > their purposes, which involve interactive data exploration of enormous > > > datasets. I'm sure that loss of speed would not be considered a > > > desirable feature for a new MPL release by many :) > > > > > > I'm certainly hoping you guys can find some mechanism to join forces > > > on this front, which I would absolutely love to see. But I just want > > > to provide a bit of context as to why MPL uses extensions like Agg and > > > relies on compiled code, which is I think a fairly critical need of > > > the project. > > > > > > Having said all this, I'd be thrilled to be proven 100% wrong in all > > > of the above, and to see a pure-python MPL that is as fast as today's > > > and maintains the image quality we have today. > > > > > > One approach that has been thrown around in the past was to have an > > > opengl based render while working interactively, that would force a > > > re-render of the same entire scene via Agg for image saving. I don't > > > know enough about the MPL internals to say how feasible this would be. > > > > Hi Fernando! > > > > what you said are valid points for matplotlib using Agg as a backend. > > And as I said, > > the default matplotlib installation should include it, no doubt about that. > > > > On the other hand, I (and I think many other users) only need the super > > quality only when saving the final plot. Of course, if it's worth the pain, > > I can install the agg > > backend and have the quality all the time, but many users will > > sacrifice the quality, > > if they can get at least some plot. > > > > If it was just me, I use Debian, so for me using any C compiled code > > is zero pain. But, > > the majority of users of sympy, are probably windows users. (At least there > > are more downloads of the windows installer, than the mulitplatform > > tarball). And I am not sure compiling anything on windows is a pleasant > > experience (honestly I > > think forcing a user of sympy compiling something on windows is a show > > stopper). > > Why would your users have to compile anything on windows? Matplotlib's windows > users just run the installer, the compilation has already been done. Am I > missing something? Right, maybe what I am trying to achieve is not really worthy. My idea is to have something integrated inside sympy, pure pythonic. I don't really want to depend on anything else. Because for everything else, there is Sage (full featured CAS system, with all the programs). SymPy is just for doing symbolic manipulation in python. Ondrej
On Jan 4, 2008 1:00 PM, Ondrej Certik <on...@ce...> wrote: > > On Jan 4, 2008 8:44 PM, Darren Dale <dar...@co...> wrote: > > Why would your users have to compile anything on windows? Matplotlib's windows > > users just run the installer, the compilation has already been done. Am I > > missing something? As I mentioned, it does meant that the project does need a volunteer to *produce* the win32 installers. That might be trivial (if that person already exists) or could require some work, but it's not insurmountable (and as I hinted, with virtualization that person can even be one of the regular unix people with only limited pain). Cheers, f
Fernando Perez wrote: > It's probably worth mentioning that one of the reasons John chose Agg > is because of image *quality* concerns. If I'm not mistaken (John and > A. Straw will correct me as needed), the OpenGL anti-aliasing quality > is positively horrible when you compare it to the quality of Agg. > Keep in mind that OpenGL is typically focused on keeping high > frame-rates for moving images, so pixel-perfect antialiasing is much > less of a concern for them, since your eye is a lot less likely to > notice such fine details (as long as there is *some* antialiasing). > For a static image, you tend to be a lot pickier, and Agg goes to > great lengths to ensure the best possible antialiasing quality. This > is part of the reason why normal television, at abysmally low > resolutions is still acceptable for viewing, while nobody would > consider a 400-line-image an acceptable photograph for most uses. You > 'stare' at the moving image only for 1/30 s or so, while you look at > the static one for much longer. Excellent summary, Fernando -- are looking to burnish your visual neuroscientist credentials? ;) The only thing I'd add is that the spatio-temporal nature of video means that, despite course spatial quantization on any single image, we perceive something with a much higher resolution essentially because we have many samples where the source is moving against the sampling array and we "fill in". Not only do we do this, so do our electronic devices these days -- upsampling (spatially and temporally) DVD players make use of algorithms to fill in pixels that weren't directly specified. And video compression codecs essentially remove information that's perceptually less significant to this filling in process. (Stop me here...) > I've never seen any opengl-based antialiasing be of that quality. But > there may be ways of achieving the same thing in OpenGL, I don't know > (and to do so efficiently and portably, without requiring specific > video cards). > > The other issue I recall is that the quality of openGL antialiasing is > highly dependent on the video card and/or driver. While that may be > OK for gamers, it's completely unacceptable IMO for scientific > publication. Granted, this page is getting a little dated, but here's what you get with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html FWIW, one cheap trick to get better anti-aliasing with OpenGL is to render the image much bigger than you need and then downsample it appropriately. As OpenGL implementations have maximum rendering sizes, this often means tiling the image. This probably wouldn't work for realtime rendering, but for saving bitmaps it would produce decent results. In general, I think we should explore collaboration (and I'm very excited about the sympy project). Yet, it's difficult for me to see how MPL could be turned into a pure-Python project with acceptable speed and retaining the backends that we support with the quality we support. All the more so with the new transforms branch.
On Jan 4, 2008 1:04 PM, Andrew Straw <str...@as...> wrote: > Excellent summary, Fernando -- are looking to burnish your visual > neuroscientist credentials? ;) Gotta start somewhere, no? :) Now I just have to convince the NSF it's true as well... Back to grant writing :) > > The other issue I recall is that the quality of openGL antialiasing is > > highly dependent on the video card and/or driver. While that may be > > OK for gamers, it's completely unacceptable IMO for scientific > > publication. > > > Granted, this page is getting a little dated, but here's what you get > with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html Thanks, that's the link I was basically quoting from memory, which I'd read when you posted it a while ago. Great reference on this topic. Cheers, f
On Jan 4, 2008, at 12:44 PM, Fernando Perez wrote: > Indeed, compiled code in a project basically forces you to have a > windows developer in the team who can build the binary installers. > These days with vmware/qemu it's not the end of the world (it can be > done in a normal computer running linux/osx) but it's still a pain for > most of us, no doubt about it. Not to open a can of trolls here, but I must strongly disagree. Why does "compiled code" mean "Windows"? I'd recommend that some OpenGL layer be used from Python. Use automake for the build system. We'd have to drop Matplotlib if it required Windows; at the moment we only have Linux and Macintosh developers (the Mac got in because it's a Unix platform, but it still took some porting). I believe that many other scientific research organizations have many Unix boxes and few Windows machines for their analysis workstations. I know it's true of the astronomy places that I've visited, but I haven't seen other science in a while so perhaps Windows has taken over science, too. But at our facility we can't support Windows for scientific development. /me runs away, covering head... ;-) - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico
Ondrej Certik wrote: > On Jan 4, 2008 7:41 PM, Michael Droettboom <md...@st...> wrote: >> Ondrej Certik wrote: >>> * freetype (this could be rewritten using ctypes) >> I see that pyglet already has a freetype wrapper using ctypes -- it >> would be interesting to see if that could be used as a starting point. >> That could be used as a starting point. (Of course, ctypes is an >> external dependency before Python-2.5, which adds a dependency to >> matplotlib). > > That is correct. I forgot about that. We do support python2.4 and it's > true that in order > for plotting to work, you need to install python-ctypes. > But python2.4 will hopefully get old soon, in favor of python2.5. Agreed. I know there are still some matplotlib users on python2.3, but they'll have to move on eventually... ;) >> I generally don't like ctypes-based wrappers since changes in the >> dependency can mean segfaults at runtime. I'm having a problem getting >> pyglet to work on my particular version of OpenGL, for instance. But >> perhaps freetype is stable enough for that not to be a problem. > > Could you please report it to http://groups.google.com/group/pyglet-users ? Sorry -- I should have mentioned I already did. >>> * Agg (this could be optional) >> On the transforms branch, Agg is used for bezier curve realisation, >> whether the Agg renderer is being used or not. This is used for things >> like hit-testing and range-setting of path collections etc. This was >> not fast enough in my earlier numpy-based implementation, since to take >> advantage of numpy, you generally have to allocate lots of memory to >> store the results in. In this particular case, each value can be >> immediately thrown away, so all that extra work was unnecessary. > > So it's needed for path collections - what is that? A collection of a large number of paths (or polygons) that need to be rendered quickly. > When I want to do > regular plots, > like plotting some set of points, is that needed too? If not, it > should be optional imho. That's actually a tough one. On the transforms branch, by the time it hits the rendering level, everything is a polycurve path. Determining if something contains curves or not (which in the current implementation would require running through the entire path, which may be quite large) would probably be too slow. >>> Compiling really sucks. >> Agreed. But there is a spectrum of suckage here. It also sucks to be >> unable to check that a call to some library that you don't provide >> (freetype) will succeed. > > That sucks too. But I think there are mechanisms to check the exact version > of the library, aren't there? There are. But the multiple versions of the library must be individually tested to have a hope of working -- whereas with the compiled model, sometimes the changes between library versions will be seamless, other times the compile will fail, both of which are preferable to segfaulting at runtime (which admittedly is still possible even when compiling.) >>>>> Another cool stuff in matplotlib is the pure python latex renderer >>>>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for >>>>> more info: >>>> Yes, the mathtext support in matplotlib is very nice, and Michael >>>> deserves the credit for taking from a package that >>>> works but has warts, to an extremely nice math layout engine using the >>>> Knuth algorithms. I'm sure others would like to use it without having >>>> to pull in all of matplotlib. With a ctypes freetype wrapper, it >>>> should be possible to build a free-standing mathtext. >>> And this is really cool. I would like to have that. :) >>> >>> We'll try to help with that one. >> Great! I'll start by looking at pyglet's freetype wrapper and see how >> far I get. > > Awesome. Please ask on the list above, as I said, Alex is quite guru, so he > will answer any technical questions. Thanks, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
> Agreed. I know there are still some matplotlib users on python2.3, but > they'll have to move on eventually... ;) Yes, we decided to drop support for python2.3, because we use decorators. But I am not going to drop support for 2.4, because Debian (my distribution) still uses it by default. :) > >> I generally don't like ctypes-based wrappers since changes in the > >> dependency can mean segfaults at runtime. I'm having a problem getting > >> pyglet to work on my particular version of OpenGL, for instance. But > >> perhaps freetype is stable enough for that not to be a problem. > > > > Could you please report it to http://groups.google.com/group/pyglet-users ? > > Sorry -- I should have mentioned I already did. Ah, so mdboom is you? I saw the headline, but I didn't look further. Nice bug report! > > So it's needed for path collections - what is that? > > A collection of a large number of paths (or polygons) that need to be > rendered quickly. > > > When I want to do > > regular plots, > > like plotting some set of points, is that needed too? If not, it > > should be optional imho. > > That's actually a tough one. On the transforms branch, by the time it > hits the rendering level, everything is a polycurve path. Determining > if something contains curves or not (which in the current implementation > would require running through the entire path, which may be quite large) > would probably be too slow. I see. In this case, it's probably not worthy to create pure python kernel. We do have some 2D plotting already, it's fast enough. But it doesn't contain so many nice features of matplotlib. > There are. But the multiple versions of the library must be > individually tested to have a hope of working -- whereas with the > compiled model, sometimes the changes between library versions will be > seamless, other times the compile will fail, both of which are > preferable to segfaulting at runtime (which admittedly is still possible > even when compiling.) I got it now. That's right. > >> Great! I'll start by looking at pyglet's freetype wrapper and see how > >> far I get. > > > > Awesome. Please ask on the list above, as I said, Alex is quite guru, so he > > will answer any technical questions. > > Thanks, Since you already asked, let's wait. :) > > Granted, this page is getting a little dated, but here's what you get > > with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html > > Thanks, that's the link I was basically quoting from memory, which I'd > read when you posted it a while ago. Great reference on this topic. That's nice enough for me. Don't forget, that I am comparing no plotting, to some plotting. Well, definitely, we try to support good interaction with external packages, like numpy and matplotlib. But builtin is builtin. :) Ondrej Ondrej
On Jan 4, 2008 1:04 PM, Boyd Waters <bw...@nr...> wrote: > > On Jan 4, 2008, at 12:44 PM, Fernando Perez wrote: > > > Indeed, compiled code in a project basically forces you to have a > > windows developer in the team who can build the binary installers. > > These days with vmware/qemu it's not the end of the world (it can be > > done in a normal computer running linux/osx) but it's still a pain for > > most of us, no doubt about it. > > > Not to open a can of trolls here, but I must strongly disagree. > > Why does "compiled code" mean "Windows"? No worries, you misunderstood me :) My point was that a linux developer could keep a vwmare image around to produce the binary windows *installer* for win32 users, if there were compiled code around. I was just explaining how even if the project has no windows volunteers on hand to generate the installers, this isn't insurmountable these days thanks to vmware. You still need a linux/osx dev who's willing to install virtualized windows and compiler, but that's a lower requirement than asking one of us to switch to win32 altogether :) Relax, anyone who knows me has already seen how big of a fan of win32 I am ;) Cheers, f
On Jan 4, 2008, at 1:08 PM, Fernando Perez wrote: > No worries, you misunderstood me :) My point was that a linux > developer could keep a vwmare image around to produce the binary > windows *installer* for win32 users, if there were compiled code > around. Oh. That's all right, then. Sorry. (Actually I might be a tad more Windows-neutral, as Python gets us halfway there... so far our user community hasn't asked for it, whew!) (lurking resumes...) - boyd