You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ax = df.plot.line(id='line')
line = ax.get_figure().get_artist('line')
2. FuncAnimation
The typical usage pattern for FuncAnimations is currently quite cobbled together: typically, the plot is created globally, and relevant Artists are stored in global variables that are accessed from the function. This means, the FuncAnimation is not self-contained but the function depends on globally accessible Artists at run-time.
Uniqueness/Scoping: One should not give the same identifier to two Artists within the same figure. Figure is the right scope because it's the outermost Artists. Widening the scope would mean global uniqueness - this seems unnecessary and more cumbersome to implement. Narrowing the scope, e.g. to Axes is also difficult as there can be Figure-level Artists that would need extra handling.
Enforcement of uniqueness: Telling people, that an ID is already used would be nice, but I would make that feature depending on the implementation. A uniqueness check can be costly/cumbersome if we don't have a central registration mechanism for the identifiers.
Naming: I originally started with name, but now prefer id. name clashes with Axes.name (and I think we'd want to be able to handle Axes as well). Also, id is a bit more clear in the sense that you should not give the same identifier to two Artists.
Mutability: While immutability makes things easier, I believe it is neccesary to allow changing the identifier after Artist creation. We sometimes create multiple Artists through factory functions and it's not always possible/reasonable to expose the ability to set ids to all of them through the factory function (e.g. errorbar()).
Lookup performance: We can get a simple implementation by adding a public/private attribute Artist.id and doing the lookup by building a nicer API around fig.findobj(lambda artist: artist.id == id). This is easy as it does not need any registration/update/check mechanism. The downside is a slow lookup (~1ms on a simple figure), because you have to traverse the whole Artist tree. I'd be ok with that perfomance for a start. One could always later introduce a registry and speed things up.
The text was updated successfully, but these errors were encountered:
I don't fully understand gid, but I think it refers to the group id in SVG (<g id=...>), so I don't expect overlap. In particular, I believe multiple artists can/should have the same gid to be grouped together. In contrast, id should be unique.
Problem
Extracted the discussion from #29422 (comment)
Proposed solution
Summary
It may be reasonable to be able to retrieve artists by a name/id. such that this would be equivalent
This alleviates the need to always hold references to created Artists.
Use cases
1. plot helper functions
These helper functions do not always return the created artists. For example we could then get hold of the Artist that is created in https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.plot.line.html via
2. FuncAnimation
The typical usage pattern for FuncAnimations is currently quite cobbled together: typically, the plot is created globally, and relevant Artists are stored in global variables that are accessed from the function. This means, the FuncAnimation is not self-contained but the function depends on globally accessible Artists at run-time.
Taking from https://matplotlib.org/stable/gallery/animation/simple_anim.html we could then evolve the API such that
could be replaced by
where we pass the figure into the function and from that retrieve the relevant artists. This would eliminate the global state.
3. Other cases of "tracking" artists
E.g. #29422 (comment) or #29422 (comment)
Design decisions
name
, but now preferid
.name
clashes withAxes.name
(and I think we'd want to be able to handle Axes as well). Also,id
is a bit more clear in the sense that you should not give the same identifier to two Artists.errorbar()
).Artist.id
and doing the lookup by building a nicer API aroundfig.findobj(lambda artist: artist.id == id)
. This is easy as it does not need any registration/update/check mechanism. The downside is a slow lookup (~1ms on a simple figure), because you have to traverse the whole Artist tree. I'd be ok with that perfomance for a start. One could always later introduce a registry and speed things up.The text was updated successfully, but these errors were encountered: