Qt SVG renderer

[Ariya Hidayat]

Hi Aaron,

> from the Plasma perspective, we also don't particularly have need for access
> to the DOM or scriptablity right now (though i'm sure we could find (ab)uses
> for them without too much trouble ;)

Good to know :-)

> as you note in your blog, things like blur are not implemented in QtWebkit's
> SVG renderer either. so we're right back to asking, "when?"
>
> obviously the answer is "sooner than QSvgRenderer will" but that is still a
> bit vague.

Compared to the fact that filters won't be in QtSvg, I would say it's
still much better, isn't it?
I'm not trying to give any hope here, I just want to make a point.

> it also doesn't help at all with the performance (both speed and memory
> overhead) question.

Hence, the exercise. Everyone can just say it's memory hungry and
slower, but how much e.g. slower? We need numbers.

> and i'm particularly unimpressed that we'll end up having to build up a set of
> API for what is really simple now (e.g. elementRect("anObjectid")) based on
> JavaScript right now (!!) and *eventualy* DOM (only minorly less "!!").
> thankfully we wrapped QSvgRenderer in Plasma::SVG so we can indeed do this
> kind of thing without breaking any SVG usage in Plasma, but still .. uck.

I'm open for ideas here.

> for Plasma to switch renderers, i'd really have to have a bettter idea of
> performance and development timelines. otherwise it'll continue to be a "wait
> and see" issue without us doing anything different on this front.

Note I didn't and won't suggest Plasma to switch the renderer. If
Plasma is perfectly happy with SVG Tiny that is supported by QtSvg,
then it should stick to that. Think of the case of WebKit's or KHTML's
SVG as "a research plan".



-- 
Ariya Hidayat, Software Engineer, Trolltech (a Nokia company)
http://www.google.com/search?q=ariya+hidayat