Technologies like OpenGL have consumed masses of time and money as well :-)
Having worked on 3D visualization of large datasets (512^3) I am pretty sure that one has to utilize the graphics hardware in order to obtain full speed. But it seems it all is about use cases. Exporting to html has the big advantage that publishing online becomes easy (preserving interactivity). For "publication ready" plots I love to use PyPlot as it gives me a lot of control over my plot. Since PyPlot is slow I favor a combination of Gtk and Winston to do interactive applications with plots Cheers, Tobi Am Montag, 23. Februar 2015 21:47:25 UTC+1 schrieb Samuel Colvin: > > Thanks for being accepting of my provocation. Some emphasis on graphics > makes sense, I just think it would be a mistake to spend too long wrestling > with c libraries when projects like threejs show how much can be done with > just javascript. Technologies like chrome, v8, html5 have consumed masses > of time and money, it makes sense to piggy back of as much of it as > possible. > > The saving file --> opening file is definitely just the first step, > websockets should allow real time data transfer in both directions. HTML5 > can definitely handle the graphs, take a look at these examples: > http://dlmf.nist.gov/21.4.F1h.webgl > > So I think there's no reason why the above example shouldn't be possible > with nothing more than the Julia standard library, WebSockets.jl, reference > to a JavaScript file and a browser. > > > > > -- > > Samuel Colvin > s...@muelcolvin.com, > 07801160713 > > On 23 February 2015 at 20:16, Tim Holy <tim....@gmail.com <javascript:>> > wrote: > >> On Monday, February 23, 2015 11:19:17 AM Samuel Colvin wrote: >> > 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). >> >> Oh, I appreciate your interaction on this. While we've made a lot of >> progress, >> there's still room for improvement in our graphics subspace, and not very >> much >> unity. (I need to check out Mike's Blink.jl, too.) Perhaps at the next >> JuliaCon graphics can be a big topic of discussion and perhaps hacking. >> >> > 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/ >> >> Those are indeed nice, but for some insight into about what's actually >> possible...check out this amazing video by Simon Danish (using his >> GLPlot.jl >> collection of packages): >> https://www.youtube.com/watch?v=nJdGHVY2b2g >> >> It's my understanding that this video was just capturing what was going on >> inside a window on his desktop, *in real time*. That would be pretty hard >> to >> achieve by saving data to files and popping up browser windows... >> >> --Tim >> >> > >> > > - 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 >> >> >
