Thanks for the quick reply. I looked into SVG.pm and found no way to 1- load and 2- apply transformations to existing objects. Most important, I forgot to mention all this must be done in real time (~25fps) sparing the cpu as much as possible, so using perl is not an option (yes, I know about SVG animation but I can't use it... read on).
Ok, it's time to clarify things a bit :
I have an app that has it's own GUI. Basically, you connect modules together, building a dataflow graph with the nodes acting as filter/generators/renderers, and the connections carrying pieces of SVG information. Here's an example :
[square generator] --------> [rotate] --------> [renderer] ^ | [some changing control value] -|
when the graph is complete you press play and watch.
I already know about the concept SVG animations, however I cannot rely on them since the animation speed is fixed (eg : I want to be able to, say, rotate a box at a speed that is a sinusoidal wave, not constant). This kinda clashes with my concept of animation, but anyway... So what I want to do is animate with API calls like
setRotationAngle(MyBox, sin(time) ) (or myBox.setRotationAngle..... )
I think I said enough so you can tell me if using inkscape would be appropriate, and if so could you answer these questions please :
- am I correct when I assume inkscape already has all the API calls I'm looking for ? - how is the internal representation of the graphical objects organised ? As an XML document would be ? A tree? - how to strip the GUI part from the core of inkscape ? - when inkscape moves to cairo for rendering, will it use glitz ? if not, why so?
thanks again Julien
So bottom line, I guess I'll be joining the inkscape dev-team :). For now, I see my own roadmap like this :
- make a clear separation between GUI and core. (arghh.. will need help on that one.. ) - get an API that
On Tue, 8 Jun 2004, Julien Keable wrote:
hello happy community,
Hi Julien,
I'm new-to/mixed-up-with SVG, and I'm starting my own SVG-friendly application. I need to load SVG files, modify/generate objects and their properties via API calls and render it in a buffer. While looking at cairo and librsvg to render SVG graphics, I realized (correct me if I'm wrong) their API didn't provide calls to access individual objects or their properties. Then I figured out using some existant app would be much smarter, as open source is starting to kick some serious mellons.
That's correct, librsvg strives to be an efficient one-pass renderer.
I don't know exactly what you're shooting for, but another option would be to use an SVG generator like Perl's SVG.pm module, which provides access to generate and modify SVG objects, and then when you need to render it, save to a file and call librsvg to render it. Obviously, this would work ok for some needs but not for others.
Then I saw inkscape and got very excited, because as a bonus, we get SVG extensions and automatic rendering technology updates and so on..
So my plan is to strip inkscape from its GUI part, or simply link the relevant CVS dirs to my own CVS, but this seems a bit harcodre to me and I'd like to hear your wisdom speak about this. (ex : which dirs/classes ? )
Yes, it's quite hardcore but we'd definitely encourage this - breaking out the renderer from the GUI has been a longstanding TODO item.
Start by looking at the architectural diagram on the main website (in the docs area) as well as the SubsystemRearchitecture link in our Wiki. http://www.inkscape.org/cgi-bin/wiki.pl?SubsystemRearchitecture
another thing I'd like is a table that looks like this :
loads SVG renders SVG has API to modify objects
ksvg cairo libart librsvg
Just to make things as clear as possible, I need to :
- load svg files
- access/transform individual objects through API (not GUI, I don't have
one) ex : rotate(MyCube, 123)
Hmm, I would suggest you check out the Perl SVG.pm module before you get too far into Inkscape's internals. If you can make use of that, it'd save you a considerable amount of effort.
- render it in some 32 bit pixel buffer (RGBA)
BTW, why is everyone is moving away from libart (inkscape, sodipodi)?
It's got a lot of little gotchas and issues. For instance, there are error messages it prints to stderr that the application has no control over, so random things get spewed to stdout. In addition it's rendering code has proven unsatisfactory. Don't read too much into both sodipodi and inkscape moving away from it; this was something that we decided back before inkscape split from sodipodi.
Bryce