Well, sticking to the Cairo API is not an option, quite frankly. I want to create something completely interactive at high speeds. I want to see, if I can actually compile parts of my event tree completely to the GPU and directly manipulate the points of, e.g. a rendered path, in GPU memory. Which is far, far away from Cairo's approach (and actually any approach I've seen so far). If there is a demand for exporting other formats, which Cairo is really great at, I much rather go for a thin wrapper, that can translate my calls into Cairo calls.
To give you a context and a better understanding from where I come from: I want visual debugging and interactive programming and at some future point in time 2D/3D manipulation capabilities comparable to Illustrator or 3DS Max. This is very hard to achieve if you have 1 million paths, or 2 billion triangles. Definitely not achievable with Cairo or what not. So while this is great stuff for the scientific community in terms of scalability, it's not immediately useful. Most scientists will be perfectly fine with something slower, as long as it has a lot of features ;) 2015-02-24 16:10 GMT+01:00 Andreas Lobinger <[email protected]>: > Hello collea > > *gue,* > > On Tuesday, February 24, 2015 at 11:17:44 AM UTC+1, Eric Forgy wrote: >> >> On Tuesday, February 24, 2015 at 3:19:17 AM UTC+8, Samuel Colvin wrote: >>> >>> (and saying someone mildly antagonistic to kick off some debate, sorry). >>> >> >> Hehe. I can't resist :) >> >> One of the nice things about Bokeh is that unlike d3, plotly or Gadfly it >>> uses canvas not SVG for it's plots which makes it way faster. >> >> >> I looked at the whole canvas vs SVG thing and went with d3 for my >> visualizations. Depending on your application, SVG can also be fast. Here >> is a nice comparison: When to Use <canvas> and when to Use SVG: The >> Scenarios >> <https://msdn.microsoft.com/en-us/library/ie/gg193983(v=vs.85).aspx#Using_Canvas_AndOr_SVG> >> . >> >> Particularly for web-based visualizations, I really want things to come >> alive, i.e. be dynamic and interactive. And as Tim was looking for, it is >> very simple to have an interaction with d3 launch some Julia code >> asynchronously. >> >> PS: TIm, if you ever have some free time to play around with javascript, >> I think you may like it. I come from 20+ years of Matlab with a bit of Java >> thrown in here and there, but have been learning javascript since August >> and love it. The old perceptions of it being slow are... well... old :) >> Even the Julia benchmark shows javascript approaching Julia speeds. >> Javascript is also fun because with little clue, you can hack something >> together easily, but the deeper you go, the more satisfying it can be. >> >> Well the point isn't that JS is still an inferior langauage or that SVG > cannot be considered a drawing API (which is true in some sense), the > problem is, you are creating a large dependency as you assume an engine > that can execute JS AND at the same time has access to a rendering engine. > Yes i agree on recent systems a browser is usually available, but even in > browser-world they come in different flavours. > > >
