This is something to shoot for, but worth bearing in mind
> that it will probably become quite tricky to maintain
> across the supported platforms. As we stood a couple of
> weeks ago, Matplotlib worked on Linux (all backends),
> Windows (at least wx, and non-GUI backends except GD), Mac
> (I believe) and probably most other platforms.
A bit better than this actually. If you hadn't been so busy having a
baby <wink>, you would have seen on matplotlib-users that Stefan
Kuzminski managed to get gd compiled on win32 and posted compile notes
and a statically linked dll. As soon as I get the time, I'm going to
test it out and update the gd info on the web page.
Also, GTK works great on win32 and OSX. So all four backends are
confirmed to work on linux, win32 and OSX, and I suspect the major
unixes but I don't have many reports.
> I know that GD is not very easy to make work on Windows,
> and I worry that if Matplotlib starts to have large
> numbers of external dependencies, it will reduce the
> overall attractiveness of the library.
> C code, in particular, can be tricky to write in an
> optimal way across platforms (e.g. Mac/Sparc are
> big-endian, X86 is little endian, making fast bit blitting
> routines potentially tricky when used in conjunction with
> a multiple set of backends.
> If we can find a truly cross-platform way to render to a
> bitmap, which is actively developed and supported on
> multiple platforms, then this would be great - my worry is
> that we end up discovering that GTK, wx, Tk and so on are
> actually the closest thing we have to this.
Interesting that you say this. I haven't done any rigorous
performance tests, but gd certainly seems to be slower than the GTK
backend, in my experience. Performance is a major issue for me, so I
wouldn't consider anything that is more than a little bit slower than
what we can do now with the native GUI solutions. I didn't mean to
imply that GD would be the image backend of choice, only one to
consider. I used it as a proof-of-concept in the gtk2 backend simply
because it already existed.
> I worry that all of the above sounds rather negative, and
> it isn't meant to be. However, (unlike most other
> Matplotlib users) my main target platform in Windows -
> force of working necessity 
- and I don't want to get
> left out of the party...
There's no worry here for you. Half of our downloads are for the exe
installer, so you're certainly not alone. And in my own work, I
distribute apps internally to the hospital where the users are
exclusively win32. So win32 compatibility and performance is an
absolute requirement.
In any event, using an image renderer to supply the GUI backends would
be optional. I don't see any reason to remove the existing
functionality we have for GTK and WX. Eg, in the backend_gtk2
example, I replaced the native GTK calls with the gd renderer in very
few lines of code. It would be relatively straight forward to mixin a
GUI framework with an image renderer, at least from a design
standpoint. Performance, as you point out, is another issue.
> However, if we can find the right way to do this, it would
> be an excellent solution.
The 3 main benefits I see are
* cross GUI image compatibility - not critically important but
worthwhile
* more sophisticated image rendering than may be available in a given
GUI backend; eg, there's no obvious way to do something like
Gouraud shading for pcolor in the gtk backend. potentially very
important
* narrow focus for addition of new features.
The latter one is important to me since I maintain 3 of the backends,
and find myself having to make improvements in more than one place
when I find something amiss, which is usually a sign that you are
doing something wrong.
The main negative is the one you pointed to: additional complexity
makes the package more difficult to install and maintain.
JDH