I'll be really happy, if everything worked without javascript and html, to be honest. Yeah it's great to use it and gives you quick, awesome looking results, but it's the lazy way out in my view. It's great that you can use Julia in a web browser, but it gets pretty restrictive, as soon as you want to do more serious things. The browser makes much sense, if the packages are really hard to install, but if Julia is easy to install, I don't see a huge difference. (Besides publishing things quickly on websites. But for that an HTML exporter should be sufficient, instead of building the whole graphics stack with web technologies) If you go down the web way, you might find yourself bound to a huge, heterogeneous technology stack, where parts are often slow, written in different languages, are just fast by an incredible amount of work (like in the case of javascript), or are simply closed source.
So this thread basically sums up the motivation for my OpenGL efforts. Yes, GLPlot should be pretty fast, at least the rendering itself. Event management and such is not that performant, and I haven't optimized much yet. But it builds upon modern OpenGL, which even without optimizations enables me to render around ~40 mio anti aliased triangles fluently on my onboard HD 4400. Here is a short overview over the state of my projects: GLPlot.jl: pretty much on hold at the moment, as I'm rewriting the whole infrastructure, to have it all use one generic rendering platform and a unified geometry stack. Romeo.jl: on hold as well, pretty much a crude prototype of something, that should become comparable to IJulia. Experimental Features (not all are activated at the moment): Plots via GLPlot, Gadfly and PyPlot can be inlined (best support for GLPlot, obviously, where you can actually click on things and change them). All variables have a default edit and visualize function, which means you can just click on your matrix and see a e.g. surface plot. The edit functions returns a visualization and a signal of that type. With that you get an editable visualization of, e.g. text, colors, or numbers. "Editable Representation" can be something like a slider or a textfield ;) Everything can be editable really, if it's the vertexes of your 3D mesh, the values of your surface, or the labels of you plot. This is all on hold, as I want to have a unified 2D/3D mesh representation, which relies on FixedSizeArrays, which both isn't in place yet. Also I'm slowly moving forward with an opengl accelerated 2D drawing api, which will be really awesome (possibly a lot faster than other libraries, including Cairo even with its new OpenGL backend, while keeping comparable rendering quality). Additionally, I'm trying to incorporate some of my newer findings into GLAbstraction and slowly have a better abstraction of the OpenGL array types. I'm also slowly moving into the direction of building prototypes for HyperSignals, which can be thought of as an high performance alternative to Reactive, which compiles code just in time for the current situation. It is thought to solve a lot of problems which I currently have in an elegant way. (Like, when can a whole event branch be executed on the GPU, when am I allowed to do multi threading and things like that). Sorry to hijack this thread, but I think it's relevant to this discussion, as it shows what could possibly achieved with native Julia alone. If you get the idea to try out Romeo, don't be disappointed, it's a little funky and might not work at all. I'm currently not wasting any time on it and instead try to put it on a solid base. Best, Simon Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: > > To coincide (approximately) with the release of Bokeh v0.8.0 I've released > a significantly improved version of Bokeh.jl: > > http://bokeh.github.io/Bokeh.jl/ > > This is the first plotting library I've built and the first proper Julia > package. I would therefore really appreciate any feedback on the plotting > interface and the structure of the package itself. > > Bokeh.jl is still a bit rough round the edges and missing some basic > features, but the examples above demonstrate what it can do. > > Bokeh <http://bokeh.pydata.org/en/latest/> is an interactive plotting > library originally developed for python which uses HTML & Javascript as > it's backend to display and manipulate plots. > > Whether by using Bokeh or other libraries, web technologies are the > obvious option for Julia to get great visualization/graphics/UI without the > pain. > > 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? >
