with qt4 bringing an svg renderer, the immediate question is: what about ksvg? the good news is that both have rather different purposes in life. qt4's svg is a svg tiny 1.2 renderer that has a very small memory footprint and low cpu requirements. the resource usage is so low that it's actually useful for devices using qtopia (which isn't accidental; that was one of the design goals). on the flip side, it doesn't provide a DOM for the svg it is rendering (it doesn't use a DOM at all internally, actually) or things like the interaction capabilities defined in the full svg spec. the goal for qt4 svg is to renders fast and accurate images.
ksvg, on the other hand, uses a DOM, provides for interaction and is suitable for use in (for instance) a web browser where the svg's it renders can meld rather nicely with the rest of the DOM based content. due to this it is heavier than qt4 svg but it also does more.
Subscribe to:
Post Comments (Atom)
3 comments:
Thansk for the precision Aaron.
Yupp. Zack told me he builds a rendering tree directly from the SAX stream of the XML.
KSVG2 is heavy weight, and gives more functionality, partly because it's part of the other "web framework". For example, one can use ECMAScript to modify the DOM, use XPath to query, and once XSL-T is in place, interact with that. So, KSVG2 allows XML applications, so to speak.
Cheers,
Frans
Hi Aaron,
Most of what you said is quite true, a good comparison! However you forgot to mention ksvg2 can handle css, even stylesheets etc. :)
Cheers,
Rob.
Post a Comment