Basically I’m trying to link the crosshair of multiple plots. This only possible with a custom span (see docs: tools — Bokeh 3.6.2 Documentation).
This works in principle however the performance is utterly terrible once you go to >50k data points. According to the docs a span will created in both cases thus I’m wondering why the performance suffers for a custom span?
import numpy as np
from bokeh.io import curdoc
from bokeh.models import ColumnDataSource, CustomJS, HoverTool, Div, Spacer, CrosshairTool, Span
from bokeh.plotting import figure, output_file, show
from bokeh.layouts import row, column
n_samples = 100_000
x = np.linspace(0, 1000, n_samples)
y = np.random.rand(n_samples)
source = ColumnDataSource({"x": x, "y": y})
vline_span = Span(dimension="height", line_dash="solid", line_width=1)
tools = [CrosshairTool(overlay=vline_span)] # allows linkage but has bad performance
#tools = [CrosshairTool(dimensions="height")] # no linkage but good performance
p1 = figure(width=800, height=400, tools=tools)
p1.line("x", "y", source=source, color='olive')
p2 = figure(width=800, height=400, tools=tools)
p2.line("x", "y", source=source)
curdoc().add_root(column(p1, p2))
You’ll need to elaborate on what does “is utterly terrible” actually means more precisely? I ran the above code on OSX on Safari and Chrome and noticed what I consider to be a slight (<0.5s) lag. Is that what you are seeing? Or something more severe?
That is exactly what I mean. However in my case (Win10, Firefox), it is much more severe (~1s). Also tried out with Chrome which performs noticeably better.
OK tried on FF on OSX and it is indeed much worse, really almost to the point of not working at all. Unfortunately, I don’t have any immediate suggestions or workarounds. All I can suggest is to make a GitHub Issue with full details, especially mentioning that this is a Firefox-specific problem.
@Maxxner actually adding output_backend="webgl" to both plots made things dramatically better on FF for me. Still slower than Chrome/Safari, but not much. Definitely in a range I would consider reasonable, at least, given the number of points. So, you might see if switching to WebGL also helps your real use-case.
@Bryan Okay I will create an issue for that. However my original question actually goes beyond the Firefox/Chrome gap & the webgl improvements but more in the direction of why the custom Span performs worse than the default. It seems like the default is independent of the sample size while the custom Span is not.
goes beyond the Firefox/Chrome gap & the webgl improvements but more in the direction of why the custom Span performs worse than the default.
I had to go check, the default span sets level="overlay", which you should do as well. That’s because there is a separate transparent canvas for overlays that can be rendered without re-rending everything else. Otherwise without configuring level="overlay", the Span renders on the same main canvas as everything else, and updating it means repainting everything (which is why WebGL is much faster).
