Changing level-of-detail has (seemingly) no effect on panning/zooming Bokeh figure

I am creating a very large Bokeh figure (approx 1200x700) as part of a server and displaying thousands of datapoints using both scatter and lines (to connect the points). The user interaction (zooming, panning) can be slow sometimes depending on the number of datapoints, so I have been experimenting with tuning the level-of-detail (lod) parameters to improve the performance. The problem is that I don’t see a difference between using the default lod parameter values and changing them to their lowest possible values (e.g. 1 for every parameter). Am I doing something wrong in how I am using the lod parameters? Below is a minimum working example with every lod parameter set to 1. When I comment them out, I don’t see any difference in performance of zooming/panning.

from bokeh.plotting import figure, curdoc
from bokeh.models import ColumnDataSource, HoverTool
import numpy as np

np.random.seed(42)
x = np.random.rand(10000) * 1000
y = np.random.rand(10000) * 1

source = ColumnDataSource(data=dict(x=x, y=y))

p = figure(
    width=1260,
    height=725,
    title="Bokeh LOD Test",
    tools="pan,wheel_zoom,box_zoom,reset,save",
    lod_threshold = 1,
    lod_interval = 1,
    lod_timeout = 1,
    lod_factor = 1
)

p.line('x', 'y', source=source, line_width=2, color='blue', legend_label='Line')

scatter = p.scatter('x', 'y', source=source, size=5, color='red', legend_label='Points')

hover = HoverTool(renderers=[scatter], tooltips=[("x", "@x"), ("y", "@y")])
p.add_tools(hover)

curdoc().add_root(p)

p.legend.location = "top_left"

A couple of comments:

• You’ve set lod_interval and lod_timeout way too small. These values are in ms and the default is like 300ms so two orders of magnitude larger. This explains the flickery-ness running your code as LOD mode turns on and off very rapidly.

• lod_factor of 1 is a no-op. The lod factor controls how many points to skip over at time when looping to draw, e.g. if you have N = 20000 points then a lod_factor of 1000 means keep 20000/1000 = 20 of them to draw.

• Probably more importantly, LOD only applies to some glyphs. AFAIK the LOD option does not really apply to lines, due to their connected nature.

I was actually just thinking about this feature the other day. IMO it is a fairly obscure and not-often used one. I do think that the docs for it are not very good at the moment. If you’d care to make a GitHub Issue about improving their docstrings I can see about clarifying things somewhat.

Of course, another (probably better) option these days is actually to use the WedGL backend with output_backend="webgl" and not rely on the LOD mode at all.

Thanks, Bryan!

We will definitely try out the webgl suggestion.

Will webgl improve the performance of the initial rendering of the scatter points and lines as well? Would you happen to have any suggestions for how we can improve that performance?

If by “initial rendering” you mean “just the actual painting to the screen”, then yes, WebGL will speed up every render, including the first. If “initial rendering” is a catch-all for anything leading up to the initial paint (e.g. serialization and network transfer overhead) then no, WebGL will not help with those things.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.