Brad,
There is not currently a non-browser "backend" (frontend? depends on your viewpoint I suppose...) for Bokeh. The idea has been bandied about, in particular I have thought about making a simple static Cairo backend. But this is not a high priority and I could not speculate on when it might happen. I have heard of others interested in pursuing Qt or Vulcan backends as well, but again I can't speculate at all on timeframes.
That said, any modern UI toolkit will come with a JS-enabled HTML widget, and this should be fine for embedding Bokeh into rich client apps. In fact I embedded a Bokeh plot into a simple WX app a few years ago as a demonstration. (Code long since lost, unfortunately). So, I'd definitely like to encourage you to give it a go with Bokeh, and hopefully we could take some useful knowledge from your experience and turn it into new examples or guidance in our docs for other users in similar situations.
Regarding the data rate, that is a layered question. Bokeh does have limited WebGL support for a few glyphs (more coming over time), and although I know 100s of thousands of points are OK, I suspect 4 million (400k times 10s) might be bottlenecked by data transfer (JSON encode/decode), though I don't know for certain. However, as you note, you probably don't have the pixels to make showing all those points at once reasonable to do anyway. So decimation should be fine. I have shown a few such demos:
* 5 Gb 4-d ocean data demo
* 2 million point timeseries
in a few talks on Bokeh. I can certainly share the code if need be, but there's actually not much to it, the hard part is the decimation, which it sounds like you have covered.
Additionally, just FYI for the future, we have a few folks working on some updated versions of the "abstract rendering" concept we've wanted to do for a while. We demo'd a new app based on it extensively at Strata and other conferences, with a census explorer app that afforded interactive navigation of the full 300 million point US census data set. The core library for this app is called DataShader, and will be open-sourced, but it will not be in the public GH repos until early 2016.
Please let me know if there are other questions I can answer,
Bryan
···
On Dec 9, 2015, at 11:13 AM, Brad Buran <[email protected]> wrote:
I'm in the process of updating my Traits/TraitsUI/Chaco neurophysiology acquisition system. As part of this process, I'm investigating whether I should switch to newer libraries (I have already decided to migrate from Traits/TraitsUI to Atom/Enaml). While Bokeh looks very interesting, it appears to be web-oriented and is not optimized for desktop applications (in which a plot window would be embedded in a GUI and receive interaction events such as pan and zoom). Is this a correct interpretation?
If, however, I could embed the plot in a desktop application (as opposed to a web browser) and pan/zoom, then the server architecture would be very nice (i.e., it would be very easy for me to allow a desktop app to connect with a remote computer).
The other thing I'm concerned about is how well Bokeh would deal with a rapidly scrolling plot. We would be acquiring up to 400,000 samples per second and updating the plot as the samples are acquired (the plot would only show a 2-10 sec window based on the zoom-level). While I can implement a decimation algorithm so that it's not attempting to cram all 400,000 samples into 100 pixels of screen real-estate. Is this something Bokeh would be able to handle efficiently?
Thanks!
Brad
--
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].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/ffdb452f-652a-400b-be07-4b046399919f%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.