Anyone who is interested in matplotlib?s architecture may be interested in
a referred paper John and I wrote about it a few years ago (which is still
mostly current): http://www.aosabook.org/en/matplotlib.html
Excerpt response to a private query about matplotlib's architecture. Some
has asked me to post it as a possible addition to development docs.
All of matplotlib started off as pure python. As time went on, it was
re-worked into a backend/frontend design. The frontend is mostly in python,
with critical portions, such as path and vector handling implemented in
C++. We are also heavily reliant upon NumPy and use its C-API in those C++
I wouldn?t say heavily reliant ? it?s actually deliberately loosely
coupled. All of the Numpy usage is isolated to one file (numpy_cpp.h), such
that it can be replaced to use the new Python buffer protocol and
memoryviews once we?ve dropped support for Python 2.6 (which we?ve done, we
just haven?t gotten around to using the buffer protocol yet). All that is
just to have an abstract way of passing large binary arrays between Python
and C++. Numpy isn?t used from the C++ side for anything another than
passing buffers across the language barrier.
We also call out to various other libraries such as libfreetype to perform
our font-handling. The frontend is also a bit of a misnomer, because it
isn't really at the front, as most people are familiar with the pyplot
interface, which sits on top of the frontend.
We don?t really use the term ?frontend? in the code base anyway. We usually
refer to the ?Object-Oriented API? and the ?pyplot API?.
The backends are what allows us to output the figures to the many
different "devices" (filetypes, GUI toolkits, etc.). Most are implemented
in python using the respective GUI toolkit's python bindings. The Tk
backend, oddly enough, is implemented in C/C++ (don't ask me why, I haven't
This is because Tkinter does not have an API to pass a binary image buffer
from Python to be displayed on the screen. We therefore had to write a very
small extension to Tk to do that. Same is true of the Gtk 2 backend. The
other more modern toolkits all have this API built-in, so we don?t have to
provide it ourselves.
and the macosx backend is implemented in Obj-C. The AGG backend is
implemented in C++. PDF and PS backends are implemented in python as well.
AGG is critically important to matplotlib's functionality. Not only does
it serve as the default headless backend, and is often mixed with the GUI
backends (TkAgg, Qt4Agg, etc.) to produce consistent results across all
platforms, it also serves as the basis for our image-handling architecture.
Just to elaborate on this: matplotlib really has two types of backends:
rendering backends and GUI backends. The rendering backends actually
perform the drawing either by rasterizing or outputting to a vector
filetype. These include Agg (which rasterizes), Pdf, Ps, Svg and Cairo. The
GUI backends create windows, copy a rendered buffer to the screen, and
provide toolbars and interaction etc. These include TkAgg, WxAgg, QtAgg,
GtkAgg etc. There are also some hybrid backends that do both, such as the
Mac OSX backend and the mostly deprecated Gdk and Wx backends.
This is a very broad-brush overview of the matplotlib architecture. It
isn't a simple layered system, unfortunately, but we do have some critical
portions off-loaded to C/C++ or NumPy. Probably some of the most
difficult-to-understand portions of the codebase isn't those parts, though.
It is the figure/axes/axis relationships for defining properties at the
right time (lots of multiple-inheritance confusion)
We don?t use a lot of multiple inheritance, and when we do, it?s usually
just as a mixin pattern.
as well as the figure/canvas/manager relationships for interactivity.
These are indeed a bit tricky to understand, but are fairly well-documented
On Tue, Feb 9, 2016 at 11:52 AM, Benjamin Root <ben.v.root at gmail.com> wrote:
Matplotlib-devel mailing list
Matplotlib-devel at python.org
-------------- next part --------------
An HTML attachment was scrubbed...