It's not simply Cairo being bad. I think it's a very nice package for it's purpose. But for me, it's also about having a unified infrastructure, which can seamlessly switch between complicated 3D rendering and 2D rendering, or have them in the same window. This all, while experimenting with OpenCL as part of the infrastructure, to enable complicated transformation at high speed, like vertex transformations coming from a physics engine. But the source for the transformations could also be a FEM algorithm running on the GPU, or what ever other scientific algorithm you want to visualize. There's not much infrastructure out there, which will let you do this without memory transfers, copies and transformations. Even though, that all your algorithms could in theory run on the GPU and share the same memory. If you step one level up, namely programming it in on high-level language, with little to no binary dependencies, you will even have less libraries offering this. My own simple 2D drawing API is just needed, to be seamlessly integrated into the whole picture, not because it's so innovative (I'm actually porting code from MapBox, which seems to be able to handle huge path definitions while keeping high quality) Actually, I might as well go back to using Cairo for drawing 2D vectors, if the MapBox port isn't working out that well. I already have a prototype for Cairo inside my infrastructure, so it shouldn't be such a big step.
2015-02-25 11:57 GMT+01:00 Andreas Lobinger <[email protected]>: > Hello colleague, > > On Tuesday, February 24, 2015 at 4:37:04 PM UTC+1, Simon Danisch wrote: >> >> 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. >> > > Which is a move into the right direction. > >> >> 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. >> > > Can you explain clearer where you see deficiencies? I agree that Cairo > makes it not easy to operate large path definitions. There is some > infrastructure today with push/pop or recording surfaces but it doesn't > look like fully efficient (for redrawing). I did also some experiments with > cairo script interpreter, and my last ideas went into: write julia code > that paints that path definion, compile it, run it (so something like a > render compiler - afaik a concept like this exists in the GL world). > > >
