I'd also point out that our two leading plotting packages, Gadfly and Winston, are both pretty good at exporting 2d plots. We're weaker at real-time interactive exploration of large datasets, and that's a pretty big hole. Since the great strength of OpenGL is that it has the kind of performance that can allow one to make some "difficult" problems (like volume rendering) fast enough to be pleasantly interactive, I'd say this should be the priority. If you can solve the export problem too, wonderful, but if constraints of time force you to choose, I urge you to callously throw export out the window and focus on interactivity :).
--Tim On Sunday, May 18, 2014 02:58:39 PM Simon Danisch wrote: > I just noticed, I haven't mentioned anywhere, that this will be OpenGL > plotting only. > There are just limited options for rendering shapes, but there are > definitely some more tricks to render shapes, than by approximating them > with a gazillion triangles. > One is, to draw pixels on a quad in the fragment shader, at every position > a shape function returns true, which also allows for some various methods > of anti-aliasing. > But this is restricted to 2D planes, as far as I'm concerned. > But I'm still learning GLSL and always find new ways of supporting magical > stuff (or nasty platform dependencies). > > I did think about svg/pdf/latex output, but this is quite a big project by > itself. But I'll keep it in mind and try to design the API in a way, that > it behaves friendly towards those kind of projects. > It might not be terribly difficult though, if every of my render primitives > implements a function, that returns the corresponding svg/pdf/latex code. > Jpeg support should be rather trivial in comparison, thanks to Images.jl =)
