Re: [matplotlib-devel] substantial refactoring of backends

[John H. <jdh...@ac...>]

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:

    Jeremy> This is something to shoot for, but worth bearing in mind
    Jeremy> that it will probably become quite tricky to maintain
    Jeremy> across the supported platforms. As we stood a couple of
    Jeremy> weeks ago, Matplotlib worked on Linux (all backends),
    Jeremy> Windows (at least wx, and non-GUI backends except GD), Mac
    Jeremy> (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.

    Jeremy> I know that GD is not very easy to make work on Windows,
    Jeremy> and I worry that if Matplotlib starts to have large
    Jeremy> numbers of external dependencies, it will reduce the
    Jeremy> overall attractiveness of the library.

    Jeremy> C code, in particular, can be tricky to write in an
    Jeremy> optimal way across platforms (e.g. Mac/Sparc are
    Jeremy> big-endian, X86 is little endian, making fast bit blitting
    Jeremy> routines potentially tricky when used in conjunction with
    Jeremy> a multiple set of backends.

    Jeremy> If we can find a truly cross-platform way to render to a
    Jeremy> bitmap, which is actively developed and supported on
    Jeremy> multiple platforms, then this would be great - my worry is
    Jeremy> that we end up discovering that GTK, wx, Tk and so on are
    Jeremy> 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.

    Jeremy> I worry that all of the above sounds rather negative, and
    Jeremy> it isn't meant to be. However, (unlike most other
    Jeremy> Matplotlib users) my main target platform in Windows -
    Jeremy> force of working necessity :-( - and I don't want to get
    Jeremy> 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.

    Jeremy> However, if we can find the right way to do this, it would
    Jeremy> 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