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).
