Qt SVG renderer

[Ariya Hidayat]

> 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