Thank you for working on this!

However, I have several serious concerns about this.

As you note, this is a un-mitigatable API change so anyone who is currently working with the return values will have their code broken with no warning. This will also break any code that is expecting to be able to look at the line or collections attributes on the Axes.

LineCollectionwith many lines is significantly more preformant than the same number of Line2D objects, I am worried that switching to individual Line2D objects will cause significant performance regressions.

A middle ground, which accepts some API breakage of not being able to find the artists in the expected lists is:

• change from using self.vlines and self.hlines to creating the LineCollection artists directly (like we already do with Line2D instead of using self.plot)
• write a very thin Artist sub-class (or duck-type?) that basically only knows enough for forward it's draw call onto its children
• add all of the created artists to the proxy / bucket artist described above (rather than calling self.add_line)
• add the proxy artist to the axes with self.add_artist.
• make sure the new artist participates it autoscaling as we expect etc

In this case we do get to fix the rendering order issues but still preserve the return type and the performance gains.

Sorting out how to do a major overhaul is part of what @story645 is funded to work on under CZI grant so hopefully the major overhaul is much closer than it used to be!

@tacaswell Thanks for getting back to me. I suspected that the change in function return would be a deal breaker, but I already did most of the changes to figure out what is going on with errorbars, so I thought I might as well put in a pull request and see what you guys think about it. I think performance is not the main issue here, if you try to plot thousands of errorbars you probably do something wrong in the first place.

I'm not very familiar with the artists, etc, so the changes you suggested most likely will take quite a bit of time for me to figure out and not sure if I will find that, but I will give it a try. Any pointers are welcome too. It certainly sounds like a much more elegant solution

Any ideas on how to force the svg tests to be run, it somehow skips them locally, but they seem required on travis?

You need inkscape locally to run the svg tests (we do comparisons after rasterization rather than text comparison and use inkscape to do that rasterization).

The very very fast summary of Artists is everything you see in the output is represented by an Airtist internally (see https://matplotlib.org/tutorials/introductory/usage.html#parts-of-a-figure). When we render a figure we create a renderer object and then pass it into Figure.draw(renderer) which in turn recursively calls the draw method of its children and so on (aka visitor pattern). In each draw method the artist has the ability to leave marks on the canvas. At the end those aggregated marks are serialized out as the svg/png/...

https://aosabook.org/en/matplotlib.html is a good reference for the overall architecture.

@tacaswell. Thank you so much for taking time to explain that. Your references have been very valuable so far.

The way I would think the objects should appear is:

1. Any previously plotted line, etc.
2. Error bar lines and error bar bars depending on barsabove
3. Any line, etc. plotted later

I think I figured out how the different artists are sorted for Axes through

I think using Line2D as a base class would be quite natural for something like Line2DWithErrorbars. Most code currently being implemented in Axes.errorbar could be moved to that new class, or left where it is for now, depending on how big these changes should be (opinions are welcome).

If you agree with me on this, I think I could manage the required changes.

The fact that all child artists are not stored in a single list is unfortunate, making it difficult to break ties by insertion order (which is more or less what we need here, I guess). I guess one option would be to complement zorder with a hidden _insertion_order which would use a global counter, and use that to break ties in zorder instead.

I pushed another implementation of this, now as @tacaswell descriped using a single Artist holding all error bar objects, in this case a class inheriting directly from Line2D. As it is mostly a line, it can be sorted in correctly with the other Line2D objects in Axes.lines. I think a lot of the complexity currently present in Axes.errorbar could be moved to that new class, but I held off doing so to see what you guys are thinking about it first.

There is something wrong with the documentation, will fix that later, but other than that it seems to pass all tests.

@anntzer: I think this would be part of the major overhaul @tacaswell mentioned to be done by @story645 over summer.

I will leave this as it is for now. With @anntzer's suggestion in #17247, these changes would be unnecessary.

I think however, putting errorbars into a single Artist container is a good idea, however, if it doesn't have to be sorted in as a Line2D the implementation probably could be optimized. I'm more than happy to work on this some more if it is considered to be useful. The errorbar function seems a bit bloated and moving that to a external class looks like a good idea to clean the code up some.

#18216 is now in, so I think we can now close this. Thank you for working on this, @cosama, and sorry it did not get merged in. If you want to work on the other things, feel free to open a PR.

@QuLogic Thanks for working on this. Awesome to see this finally getting into matplotlib. Was happy to help.