From kde-core-devel Wed Aug 06 17:03:16 2008 From: "Ariya Hidayat" Date: Wed, 06 Aug 2008 17:03:16 +0000 To: kde-core-devel Subject: Re: Qt SVG renderer Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=121804225612419 > Rendering icons is not the only usage of SVG inside KDE, of course. In games > and edu we are using the whole QtSVG API, including getting the bounds of > elements, selectively rendering only portions of it, etc > Maybe it is all easily portable to the webkit renderer, with roughly the > same speed. This is something we can test during the Akademy coding week. Without actually giving it a try, I'm pretty confident this is possible using WebKit's SVG. Once we expose the DOM API, this would be even easier. > However, if it is not the case, I really think the best solution would be to > improve QtSVG, which already has the perfect API, to simply handle the files > it is not handling correctly right now, up to a reasonable portion of the > spec. I would like to avoid a change of API and engine if at all possible, > specially in the middle of a stable 4.x series. Between having no control > over QtSVG development schedule and priorities and having no control over > WebKit I think the former is preferrable, as we have good contacts and are > already using it. Technically we could have a KSvgRenderer that has both QtSvg's and WebKit's renderers as the back-end (with the same API so that the applications do not need to be changed). I'm pretty busy with some other stuff, but I will try to come up with a prototype for this (feel free to beat me!). Then we can compare both in terms of speed and performances. Thus, whichever the back-end will be finally chosen, at least we have solid technical reasons based on this analysis. > I would prefer to educate artists on which features are > not supported instead of having to rewrite SVG rendering code for all games. I fully agree with this. -- Ariya Hidayat, Software Engineer, Trolltech (a Nokia company) http://www.google.com/search?q=ariya+hidayat