matplotlib-devel Mailing List for matplotlib

On Wednesday 28 January 2004 10:06 pm, John Hunter wrote:
> I just finished reorganizing the backend code. The most significant
> change is that backends no longer derive their own figures. Figures
> now derive from Artist and are totally backend independent. All the
> GUI functionality formerly in FigureBackend, is now in a new class
> FigureCanvasBackend, which does Rendererer installation, GUI event
> handling, etc... For GUI classes, FigureCanvasBackend should derive
> from a widget you can insert into a widget container.
>
> FigureManagerBackend is initialized with a canvas. The attribute name
> canvas is standardized across backends.
>
> So the containment is manager contains canvas contains figure.
>
> The importance of these changes is
>
> 1) Backend switching is now perfected since figure instances contain
> *no* backend specific information - of course mainloops will prevent
> switching between gtk and wx
>
> 2) This enables a backend to render to any other non interactive
> backend (eg, PS saves from GTK or WX). More importantly, it
> enables us to have a sophisticated image backend (eg agg which
> supports alpha and antialiased drawing http://www.antigrain.com/)
> or gd (which is getting better all the time) and render to the GUI
> from the image - see attachment below.
>
> In other words, instead of each GUI implementing their own drawing
> and dealing with fonts and rotation and window extents etc, all
> this can be relegated to a single high quality image backend and
> the GUI canvas updated from the image. Since we're already doing
> double buffered drawing, there would be no little or no additional
> performance hit.
>
> All at once this buys us font standardization across GUI backends,
> arbitrary text rotation across GUI backends, and pixel for pixel
> compatibility across GUI backends. I think it's an idea worth
> serious consideration, so please weigh in.
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.
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.
> It would probably entail some specialized C code to move images
> from the image backend to the GUI canvas for speed. I've
> implemented a proof of concept GTK backend called GTK2. It uses
> GD for drawing the image. It's slow, because I use python to
> transfer the image, but it works. And note it is only 80 lines of
> code (matplotlib.backends.backend_gtk2), which shows how easy it
> is to plug an arbitrary image renderer into an arbitrary GUI
> backend under the new framework. As before, you can also export
> PS and EPS from this backend.
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.
> If you want to try this out, you'll need gdmodule-0.51 (and the GD
> dependencies described at
> http://matplotlib.sourceforge.net/backends.html#GD). gd lib has
> recently added clipping and antialiased line drawing. I've
> patched the 0.51 gdmodule wrapper to add support for this and will
> email the maintainer the patch when I get some time. In the mean
> time, just replace _gdmodule.c in the 0.51 distro with the file
> I'm attaching below.
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...
However, if we can find the right way to do this, it would be an excellent 
solution.
> This CVS update breaks WX (sorry Jeremy!). Since Jeremy is otherwise
> occupied :-), I'll try and port WX tomorrow.
>
> For those of you using matplotlib in GUI apps, the new setup requires
> some minor (one liner) API changes -- see embedding_in_gtk.py for an
> example and the CVS file API_CHANGES for more info

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

I've spent the last couple of days refactoring the matplotlib
backends, fixing bugs and adding some functionality. Here's a
synopsis of what's new. I encourage everyone to try it out so
complaints and bugs can be handled before the major release.
** Note there are some API changes so please read about this below **
** Note, GD users, GD rendering is significantly improved in my
 opinion. However, some of new functionality requires a recent
 version of gd and a patch of the latest gdmodule, see below **
What's new in matplotlib 0.50e
 GD supports clipping and antialiased line drawing. The line object
 has a new 'antialiased' property, that if true, the backend will
 render the line antialiased if supported. **You will need to
 upgrade to gd-2.0.15 or later and gdmodule-0.51. You will also need
 to replace _gdmodule.c with the code as described at
 http://matplotlib.sourceforge.net/backends.html#GD.
wild and wonderful bar charts
 You can provide an optional argument 'bottom' to the bar command to
 determine where the bottom of each bar is, default 0 for all. This
 enables stacked bar plots and candelstick plots --
 examples/bar_stacked.py. Thanks to David Moore and John Gill for
 suggestions and code.
Bugfixes (by backend)
 * All : the yticks on the right hand side were placed incorrectly,
 now fixed
 * All : ticklabels now make a more intelligent choice about how
 many significant digits to display
 * GD : An int truncation bug was causing the dotted lines to
 disappear
 * GD and GTK : Fixed line width to scale with DPI
 * GD : Fixed small text layout bug
 * GD : Fixed the constant for GD which maps pixels per inch - this
 should give better agreement with other backends witht he
 relative sizes of objects
 * GTK : Dash spacing was not properly scaling with DPI
Figure backend refactored
 The figure functionality was split into a backend independent
 component Figure and a backend dependent component
 FigureCanvasBase. This completes the transition to a totally
 abstract figure interface and improves the ability the switch
 backends. See the file
 http://matplotlib.sourceforge.net/API_CHANGES that comes with the
 src distro for information on migrating applications to the new API.
 All the backend specific examples have been updated to the new API.
Enjoy,
John Hunter

As we talked about a few weeks ago on matplotlib dev, I finally got
around to refactoring the AxisText handling to make it backend
independent. In a nutshell, the renderer now implements draw_text,
which takes a matplotlib.text.Text instance. Thus text behaves more
like the other artists in the figure (lines, patches, etc...). The
renderer also has to implement a get_text_extent(text) method which
does the work formerly done by AxisTextWX.get_window_extent.
This clears the way for easier and better backend switching (eg,
saving PS from GTK or WX backends). I've ported the GTK and PS
backends to the new API, and will start on GD after this email. CVS
is updated. I've uploaded a snapshot to
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.42c.tar.gz
in case sf mirrors are lagging.
Jeremy, this probably won't be hard for you; basically just move all
the relevant AxisTextWX methods to RendererWX, with minor rewrites.
Take a look at the GTK backend for inspiration -- I do some cacheing
of font properties for efficiency with layoutd, which caches pango
layouts using text properties as keys.
I've also added a file to CVS called API_CHANGES, where I've
documented all the API changes. You may want to take a look at this
too.
Thanks!
John Hunter

John Hunter said:
>
> I'd like to refactor text so that backends will no longer need to
> implement classes derived from AxisTextBase, but rather provide a
> RendererBackend.draw_text method (as Jeremy suggested many moons ago).
> This will enable easy switching of backends in midstream, as discussed
> in the last couple of days on matplotlib-users. One important
> limiting factor in the current implementation is the fact that axes,
> labels, etc.... instantiate derived AxisText classes. Thus backend
> specific implementations inadvertently creep into (what should be)
> backend-independent interface classes, like Axes, Legend, Tick, Axis,
> etc...
>
> I think we should implement a Text(Artist) class which is totally
> backend independent (analogous to Line2D and Patch) with most of
> protected attribute data defined in AxistTextBase. This class would
> store all the relevant text properties (fontsize, fontname,
> fontweight, etc) in a standardized way, and provides a few backend
> independent utility funcs. The renderer would implement get_text_bbox
> and draw_text, each of which take a text instance as an argument;
> these two funcs, are the workhorses of text implementations.
>
> Jeremy, do you see any major problems with this proposal vis-a-vis wx?
The trickiest problem is that WX requires a device context to be able to
determine the size of a given piece of text, since in WX, GetTextExtent()
is a member of wxDC. This was a major pain when implementing text in
backend_wx, and is one of the messier pieces of code. Provided that the
implementation only requires the calculation of text extent when there is
a gc instantiated, we should not have much problem. From the sound of you=
r
proposal, this would be the case.
> On a related note, we should shoot for standardization of font names
> for the next major release. Which fonts does WX provide, and which
> should be part of the core?
WX provides the following aliases (you'll see some of them used in
backend_wx):
wxSWISS - a Sans-serif font
wxROMAN - a Serif font
wxSCRIPT - a cursive font
wxDECORATIVE - not sure - never used it!
wxMODERN - a fixed pitch font
wxDEFAULT - default - seems to be same as wxMODERN on Windows
The mapping to platform fonts depends on the WX platform, but there is a
further complication: non-TrueType fonts cannot be rotated on Windows
platforms, and some of the above are defined as non-TT fonts.
I suppose that we should have a dictionary which should be populated by
the backend. For backend_wx, I'm rather inclined to choose the some of th=
e
standard Windows fonts, rather than the WX defaults. On Linux, I really
need to look into anti-aliased text, but it probably makes sense to use
those nice new fonts supplied with Gnome 2 (as they are GPL). This means
that I may have to introduce a platform dependency into backend_wx to
ensure that a TT font is always chosen. We should also ensure that the
user can specify platform fonts if they really wish (again, backend_wx
allows for this by checking for a font name which is not in its
dictionary).
I should also remind you that (since the backend will no longer be
responsible for scaling), WX does not cope properly with scaling/rotation
of font sizes over 60 pts on all platforms. I currently simply clip the
maximum font size at 60 in backend_wx (which works fine in practice since
this is always readable) - it may be advisable to be able to cope with
this (e.g. let the backend clip point sizes it cannot handle, provided
that it correctly returns the text extent in such a case).
Overall, it's a very good idea. I can't see any major issues, and I think
I've outlined the minor ones.
Regards
Jeremy
> Thoughts?
>
> JDH
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I'd like to refactor text so that backends will no longer need to
implement classes derived from AxisTextBase, but rather provide a
RendererBackend.draw_text method (as Jeremy suggested many moons ago).
This will enable easy switching of backends in midstream, as discussed
in the last couple of days on matplotlib-users. One important
limiting factor in the current implementation is the fact that axes,
labels, etc.... instantiate derived AxisText classes. Thus backend
specific implementations inadvertently creep into (what should be)
backend-independent interface classes, like Axes, Legend, Tick, Axis,
etc...
I think we should implement a Text(Artist) class which is totally
backend independent (analogous to Line2D and Patch) with most of
protected attribute data defined in AxistTextBase. This class would
store all the relevant text properties (fontsize, fontname,
fontweight, etc) in a standardized way, and provides a few backend
independent utility funcs. The renderer would implement get_text_bbox
and draw_text, each of which take a text instance as an argument;
these two funcs, are the workhorses of text implementations.
Jeremy, do you see any major problems with this proposal vis-a-vis wx?
On a related note, we should shoot for standardization of font names
for the next major release. Which fonts does WX provide, and which
should be part of the core? 
Thoughts?
JDH