[Matplotlib-devel] Response to architecture query

Michael Droettboom mdroettboom at continuum.io
Wed Feb 10 23:48:50 EST 2016


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

On Tue, Feb 9, 2016 at 11:52 AM, Benjamin Root <ben.v.root at gmail.com> wrote:

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++
> parts.
>
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
> a clue),
>
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
in backend_base.py

Cheers,
Mike


>
> Cheers!
> Ben Root
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>-- 
Michael Droettboom
Continuum Analytics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160210/055fbf48/attachment-0001.html>


More information about the Matplotlib-devel mailing list