SFML Backend

[jasonbeach]

I'm sure I'm like many who are frustrated with the extremely limited options there are for plotting in C++. I really like this library (see here for a particle filter demo I made), but like others who want real-time performance are left wanting with the gnu-plot backend (it absolutely blows my mind the only API to that library is through pipes). I am not super familiar with OpenGL, but was looking at SFML since they recently released version 3.0 of their library. I had their demo built and running in less that one minute after cloning the repo and had a simple ball bouncing around the screen in 15 minutes without looking at the documentation. It was really pretty intuitive.

I'm curious what interest there would be in pulling in an SFML backend if I started working on one.

[alandefreitas]

Yes. I'm also frustrated by that. :)

Gnuplot was a terrible choice, and we learned a lot from other mistakes in this library. However, I don't have the time to implement a new version. If anyone is willing to take over v2 of this library, I'm happy to help and guide them.

• Gnuplot provides no control over details, and the high-level features break between versions. My intuition is also that the backend in Matplot v2 should be SFML+Cairo. Or SDL+Cairo. The backend interface should be more like Python's matplotlib interface: just a few functions to plot lines, etc. The library would handle all other transformations because they're always the same. Gnuplot makes that impossible. But once we get this right, people could write their own backends more easily and the choice of SFML+Cairo or SDL+Cairo is not even that relevant anymore. A basic backend could just write the plot to the console. What's important is getting rid of Gnuplot. Once we do that and the interface is simplified, people can easily write whatever backend they want (OpenGL, QT, Webassembly, ImGui, the console, or whatever) by defining a few functions.

• Another problem with backends now is that people want different kinds of representations for points and colors. This is not really a concern in MATLAB or Python's matplotlib but it makes a huge difference in C++ applications. This probably implies we would need templated canvases/backends and bring over some concepts from Boost.GIL to matplot. This way, the backend member functions can have any type that satisfies the point/line/color/... concept instead of relying on a specific representation. Of course, these templated backends could be (in later iterations of the library) type erased in the implementation to reduce compile times.

• A third problem is the dual interface. Python's matplotlib provides an interface based on classes and an interface based on free functions. The rationale for the second interface is to make it easier for people to migrate from MATLAB. We inherited this dual interface, but nowadays, that makes no sense at all. Very few people are still migrating from MATLAB, and the free function API is even less suitable for C++ applications. This problem is easy to solve as we have to remove the free functions.

Still, at this point, most member functions in the figure and axes classes also need to be removed. A figure has at least one member function for each plot type. And the functions are duplicated on the axes and figure classes. Calling the function on the axes puts more content on the chart, and calling the function on the figure redirects the call to the default chart. This is repetitive and prone to errors. What's worse, that pattern from Python, when translated to C++ means we have to have all headers for all plot types included in figure header file. There should be no member functions attached to plot types. A figure is simply a sequential container of axes and axes are just sequential containers of plots. This way, users can also get used to the idea of writing their own plot types, by just defining how the inputs should be represented as fundamental data in the axes. If some plot type becomes very popular, we can port it to the main library. A minor point here: these names also came from matplotlib who took them from MATLAB, but the names are really unintuitive. It makes sense to rename them to something like figure -> figure, axes -> subplot, plot -> ?, backend -> canvas.

A fourth point we need to improve is the documentation. The documentation is only composed of lots of examples: code and figures. The code examples are used as tests, but this is not great. We should have the manually written exposition describing the concepts in an intelligible order and the reference for the headers, which can be generated with mrdocs.

If anyone is willing to take over v2 of this library, I'm happy to help. I'd like to see this situation improve, even if it's by some new library or by someone else.