merging sympy plotting stuff with matplotlib

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 <ondrej@...583...>
Date: Dec 30, 2007 7:33 PM
Subject: merging sympy plotting stuff with matplotlib
To: matplotlib-devel@lists.sourceforge.net

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

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 Dec 30, 2007 12:33 PM, Ondrej Certik <ondrej@...583...> wrote:

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

···

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)

Hi Michael, John and Gael,

sorry for the later reply (holidays and stuff...)

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

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

We'll try to help with that one.

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

Ondrej

···

On Jan 1, 2008 4:51 AM, Michael Droettboom <mdroe@...31...> wrote:
On Jan 1, 2008 3:51 PM, John Hunter <jdh2358@...149...> wrote:

On Dec 30, 2007 12:33 PM, Ondrej Certik <ondrej@...583...> wrote:

On Jan 4, 2008 3:48 AM, Gael Varoquaux <gael.varoquaux@...427...> wrote:

On Mon, Dec 31, 2007 at 12:40:26AM +0100, Ondrej Certik 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).

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

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

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. :slight_smile:
>
> 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 7:41 PM, Michael Droettboom <mdroe@...31...> 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 :slight_smile:

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 Jan 4, 2008 11:55 AM, Ondrej Certik <ondrej@...583...> 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).

Ondrej

···

On Jan 4, 2008 8:19 PM, Fernando Perez <fperez.net@...149...> wrote:

On Jan 4, 2008 11:55 AM, Ondrej Certik <ondrej@...583...> 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 :slight_smile:

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.

[ oops, this was meant to be on-list]

Hey Ondrej,

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 Jan 4, 2008 12:36 PM, Ondrej Certik <ondrej@...583...> 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?

Darren

···

On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote:

On Jan 4, 2008 8:19 PM, Fernando Perez <fperez.net@...149...> wrote:
> On Jan 4, 2008 11:55 AM, Ondrej Certik <ondrej@...583...> 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 :slight_smile:
>
> 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).

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 8:44 PM, Darren Dale <darren.dale@...143...> wrote:

On Friday 04 January 2008 02:36:06 pm Ondrej Certik wrote:
> On Jan 4, 2008 8:19 PM, Fernando Perez <fperez.net@...149...> wrote:
> > On Jan 4, 2008 11:55 AM, Ondrej Certik <ondrej@...583...> 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 :slight_smile:
> >
> > 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?

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? :wink: 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.

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

:wink:

   - boyd

Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
Socorro, New Mexico

···

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.

Ondrej Certik 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... :wink:

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

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

···

On Jan 4, 2008 7:41 PM, Michael Droettboom <mdroe@...31...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

No worries, you misunderstood me :slight_smile: 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 :slight_smile:

Relax, anyone who knows me has already seen how big of a fan of win32 I am :wink:

Cheers,

f

···

On Jan 4, 2008 1:04 PM, Boyd Waters <bwaters@...451...> 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"?

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

···

On Jan 4, 2008 1:00 PM, Ondrej Certik <ondrej@...583...> wrote:

On Jan 4, 2008 8:44 PM, Darren Dale <darren.dale@...143...> 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?

Excellent summary, Fernando -- are looking to burnish your visual
neuroscientist credentials? :wink:

Gotta start somewhere, no? :slight_smile: Now I just have to convince the NSF
it's true as well... Back to grant writing :slight_smile:

> 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 1:04 PM, Andrew Straw <strawman@...36...> wrote:

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

···

On Jan 4, 2008, at 1:08 PM, Fernando Perez wrote:

No worries, you misunderstood me :slight_smile: 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.

Agreed. I know there are still some matplotlib users on python2.3, but
they'll have to move on eventually... :wink:

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

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

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

Ondrej

Ondrej