Vectorized annotations/glyphs #12487
Replies: 4 comments 1 reply
-
I don't have much to add here beside history. I will explain how things came to be how they currently are, which may be helpful to inform future work.
However:
And that's causes the tension. It became impossible to manage glyphs that could be configured with both data- or screen-space coordinates [1] while making efficient use of the spatial index at the same time. So things were split:
I am not at all opposed to moving toward some sort of unification, but whatever the proposal, it needs to square that circle. That might be by having glyphs that toggle off spatial indexing if screen-space coordinates are used. That maybe doesn't sound too bad until you consider the data/screen space could be changed dynamically at any time. Or maybe we ditch the spatial index altogether for something else that can work well-enough in all cases. I also think, even if there is a unification of implementations, that there is conceptual value in having dedicated API for "annotations" because those are common concepts in the dataviz world, and we should map to user expectations whenever possible. [1] or even both! earliest glyphs could have "data" for x and "screen" for y |
Beta Was this translation helpful? Give feedback.
-
Specifically regarding the current PR #12677 I have a number of concerns:
Adding new things has knock on effects for documentation and gallery, and associated costs if there are churn. I am opposed to adding anything new until there is a documented and agreed plan forward. Here are some things I would advocate FOR:
And AGAINST:
There is continued instructive value in taxonomies, even if the implementation details converge to be identical. So, examples of questions:
i.e. do we want to say: "Annotations with data sources must support vectorization and hit-testing". Is there a meaningful name to distinguish vectorized annotations with data sources (like spans or labels) from those without? (i.e. a legend, or colorbar)? I think more typically the former might just be "annotation" and the latter be a "guide". We never previously defined a categoriy for guides, but we could, as a matter of grouping and documentation. And I am sure others. I don't want to "answer" these questions ad-hoc, one at a time, since: that is how we got to where things are currently. |
Beta Was this translation helpful? Give feedback.
-
cc @bokeh/dev this is briefer than I had hoped to write down, but I am under a bti of a time crunch. I hope this gets the high-level idea across Past / Future
These things made seemed reasonable at the time, but Bokeh was much smaller than and some of the assumptions no longer line up with with users actually want. It's clear that there is a demand for annotations to participate in legends, hit-testing, etc. So I think a simple solution is to re-focus along these definitions:
Glyph = CDS + DrawI would keep things this simple. It's easy to explain and implement. More specifically:
What I do think needs to happen is that we develop some way to automatically keep track of which glyphs offer what, and include that information the docs. E.g. right now there is just a manual wiki page for hit-testing that is often out-of-date. Annotation is an actionBy his I mean that the docs should re-focus away from, e.g "Here is a PlanIf folks like the general shape of this plan, there's still details to figure out:
What would be helpful is for someone(s) to sit down and do an actual census of all the current annotations and document exactly how far or close they already are from "being a glyph". |
Beta Was this translation helpful? Give feedback.
-
There are a few historic issues about vectorized annotations (#9955, #11015) that I don't want to append to so I am starting a new discussion here.
I have a use case for vectorized annotations which are all based on identifying vertical lines (e.g.
VSpan
) and vertical blocks (e.g.BoxAnnotation
orBand
) in timeseries plots, i.e. line plots where thex
values are monotonically increasing. You can add individual annotations now, but I would like to be able to add a large number of them, let's say a million (in a very long timeseries that you only display a part of at any one time).There is the possibility of vectorizing the specific annotation classes of interest, but the requirement for such large numbers means that they need to the glyphs rather than annotations to have decent performance. If they have to be glyphs, what are the features missing from glyphs that are needed for this annotation-like use case?
In the short term the way forward seems to be to implement the missing features listed above for glyphs, then create two new glyph classes. Longer term there is the question of what to do with annotations and glyphs. Do they remain separate class hierarchies, or should they be combined into one with support for both possible forms of behaviour which is configurable by the user as required? If they are combined into a single class hierarchy does that exclude specific awkward annotations like LaTeX rendering ones that are potentially quite slow to render if vectorized?
Beta Was this translation helpful? Give feedback.
All reactions