The project is about OpenGL rendering/plotting and therefore the only sensible export can be a bitmap of the rendered scene. When rendering this into an offscreen buffer and mapping this onto a cairo surface one will automatically get png, pdf, ps, and svg export. This definately should not be priority number one but as it is not such a big task this is at least something one can keep in mind.
Am Montag, 19. Mai 2014 03:50:28 UTC+2 schrieb Tim Holy: > > 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 > =) >
