I think having the
option for vectorized would be great.
M aybe we
could consider the vectorized a special case and require
the explicit use of “field”
from properties? And if you don’t use “field” your input is always
considered a value?
On 3/28/16 10:04 AM,
In course of adding a Label annotation (the current
PR is at: ), I generated
a couple of questions about the current annotations
implementation. Note: the distinction between glyphs and
annotations is that annotations don’t support hit-testing and
You received this message because you are subscribed to the Google
Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To post to this group, send email to [email protected]ntinuum.io.
To view this discussion on the web visit (https://groups.google.com/a/continuum.io/d/msgid/bokeh/2dbbd068-d64f-4b57-b297-9510d7bae64a%40continuum.io?utm_medium=email&utm_source=footer) .
For more options, visit .
Namely, is it worth vectorizing the implementations of the
current Box and Span annotations?
Currently, each annotation is individually created (here's
an example from the User
Are there cases and/or visualizations where the user would
want to create and manage such a large number of annotations
that the non-vectorized implementation would be a problem?
If box and span annotations are acceptable as is, would
having vectorized Label annotations be a confusing api