Answers inline below. But generally I'm not suggesting that Bokeh.jl is a complete or a viable all round option yet: I was just making a general point (and saying someone mildly antagonistic to kick off some debate, sorry).
On Monday, 23 February 2015 18:17:24 UTC, Tim Holy wrote: > > This looks interesting, I should definitely give this a whirl sometime. > > On Monday, February 23, 2015 09:38:45 AM Samuel Colvin wrote: > > I suggest (and I assume I'm about to get shot down) that the Julia > > community stops messing around with any OS specific graphics code and > > adopts HTML for all future visualizations. Are there any cases where > that > > wouldn't work? > > I'm pretty ignorant about HTML, so pardon some stupid > questions/observations: > > - I have the impression that Web3D seems to be a fairly limited subset of > what > OpenGL offers > I think you're probably right about WebGL, Bokeh doesn't have any support for 3D plotting yet, although I read somewhere (can't find it now) that they're looking at all the options and will work on 3D when they decide on a good approach - maybe that says a lot in itself. For some examples of 3D plotting in the browser plotly have some pretty cool demos: https://plot.ly/python/3d-plots-tutorial/ > > - I'm worried about the overhead of plotting huge datasets. Because I'm > too > lazy to check for myself :-), can you describe how do you pass data to > Bokeh? > Can you do it without making a copy? (I.e., in the RAM of your machine, > there > is only one copy of the data, ever, and both the julia side and the HTML > side > use the same chunk of RAM.) If so, this may not be so bad. If conversely > you > have to convert to ASCII or something, that's a dealbreaker. I'm not sure it's a dealbreaker but all Bokeh.jl does is write an HTML file with a reference to bokeh.js and insert the plot data in a big clump of JSON. It then just prompts your default browser to open that file. I know it sounds inefficient, but in the end there's a finite limit on how much data you should ever have to pass to a plot - enough data to fill the screen. If your passing GB (or even MB normally) of data to the plot there's a lot of down sampling you can do before it will be noticeable in the plot. That down sampling should be done in Julia, but obviously that's not started yet. The timing above is just the time taken to generate and write the HTML file, that's why I included (in my first message) a manual measurement of how long it take to display the data in chrome - about 6 seconds. > - Can you point me to how one writes callback functions? (User clicks on a > single point on a plot, I want it to call back to my *julia* code so I can > do > some more detailed analysis/visualization on the data corresponding to > that > particular point. I don't want to have to write that code in javascript.) > I > imagine this is possible (probably some kind of socket communication?), > but > I'd love to have someone point me to how it's done. There may be > circumstances > where one wants fast callbacks, although for interactive usage I expect > that > callback time will be dwarfed by the rendering time. > Bokeh can do this but not Bokeh.jl yet, It should just require sockets and will call a function in Julia so no javascript required. > These are the things that make me worry about relying on HTML/javascript. > I > also recognize that path holds some attractions. Yes the ease of installation, publishing and transferring HTML plots is pretty cool. Do you know of another plotting library which has a self contained export format for interactive plots which virtually every computer in the world has a viewer for? > --Tim > >
