When the same function is executed multiple times on a ColumnDataSource in a Bokeh server and the rendering is delayed, is there a way to refer to the execution queue and reflect only the latest execution requests by deleting older ones and plotting only the latest five data points?
I want to solve the phenomenon where the plot updates continue for a while after many inputs have been received.
There’s not a lot of context here, I don’t really have a clear picture of your situation, so I will just toss out some references that might be potentially useful:
The stream and patch methods on ColumnDataSource can be used to perform much more efficient incremental updates on data sources without re-sending the all the the data.
The hold and unhold methods on curdoc() can be used to suppress events for the duration of the “hold” and also have a mode that can coalesce multiple changes to the same object at the end of the hold and collapse them to a single event.
Some widgets have a value_throttled property in addition to their value property. The throttled value will only update at the “end” of an interactive event, e.g. for a slider it will only trigger a single event on mouseup, and not generate events for all the intervening values.
There’s not really enough information to say which of these might be applicable to your use case, but hopefully can give you some ideas to try out.
Using the third solution might achieve something similar, and I also think it might require programming in Python itself rather than using the API within Bokeh. Firstly, the plot I am trying to execute is simplified as follows: Figure1 and Figure2 display the range of arrays as time series data.
Currently, since I am trying to move several elements simultaneously, updating the figures takes time. If multiple inputs are made into the widget, the update process continues for a while.
Of course, optimizing the drawing process for efficiency is an important approach. However, since it is possible to input more data than can be processed in real-time, the phenomenon described above occurs, making it inconvenient to use.
Therefore, to eliminate this, if I can know how many inputs have been received when starting a new drawing as shown in the diagram below, we can discard inputs older than a certain threshold (e.g., three) and process the first of the most recent three inputs.
By repeating this, I think I can avoid the phenomenon where the drawing update continues for a while after the operation is finished.
This is just an idea of whether such a thing is possible. My thought is that any method that can solve or mitigate the phenomenon described above is acceptable.