Refactored matplotlib ElementPlots by adding higher-level API #438
The general idea behind this PR is to simplify the implementation of matplotlib plotting classes to reduce redundancy and make it easier to implement new matplotlib plotting classes.
Previously the main methods to implement a plotting class were:
To make this old API workable a lot of plotting classes implemented custom workarounds, e.g. so that each plot didn't have two separate implementations to unpack the element. However in developing the bokeh backend I came up with a better solution. I've now ported some of the ideas from the bokeh backend to matplotlib. It's important to mention that because the matplotlib API is sometimes awkward this new API is entirely optional and some plots will retain the old API for now.
The general idea is to separate the unpacking of the data and keyword arguments from the element from the actual plotting. The ElementPlot baseclass now has a default implementation of
The signature for these methods is the following:
Overall implementing all this roughly halves the plotting code required and in future when matplotlib provides a better interface to update existing artists, it should be possible to feed he output of
Okay I was wrong the 3d stuff wasn't the only change. There are three display changes:
The first two are fixes/improvements and I really don't know what to do about 3). All three are very minor and purely aesthetic changes, so I'll focus on documenting now.
Made a few minor comments but overall it does seem like a nice improvement. As it is a fairly large PR, I have a few general comments:
Anyway, I'm happy to merge once these issues are addressed. Frankly, I expect we will find bugs related to this refactor but I do think this is worth having cleaner, more easily understandable code.
I've carefully reviewed the test data changes and listed the 3 things that have changed above. The only thing I'm sort of worried about is the VectorField changes as their width has changed slightly and I can't figure out why.
Definitely a good idea.
We've always been putting the axis and figure in it, and apart from that it's generally only used for artists. The artist key is treated somewhat specially as that is where the legend code expects to find the artist and by default that is what gets removed if you don't define an