Qt SVG renderer

[Aaron J. Seigo]

On Wednesday 06 August 2008, Ariya Hidayat wrote:
> > 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?

oh, absolutely better. just not inspiring (yet) =)

> I'm not trying to give any hope here, I just want to make a point.

*nods*

> > 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.

exactly; i don't have time right now (stupid Akademy thing ;) to get them, 
however. it's just something that people tend to skip over when seeing the 
possibility for "more features!" =)

and i really don't care about the extra library dependency, as we already use 
QtWebkit in Plasma .. it's all about runtime efficiencies for us.

> > 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.

if there was a similar convenience API to the Webkit SVG renderer as we have 
with QSvgRenderer, that would be great. otherwise we'd have to do it ourselves 
in Plasma::Svg, which means that it at least needs to be possible. the bonus 
points come from having this functionality in QtWebkit so others can benefit 
from it too, not just Plasma people.

> > 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.

it works, but we'd like more (we're greedy little bastards aren't we? ;)

these jump to mind in particular: 

 * filters like blur and mask support would be great for artists.

 * ability to query what element is in the svg at QPointF(x, y) given document 
size QSizeF(n, p)

we still need the ability to selectively render, query bounding boxes, etc.

> Think of the case of WebKit's or KHTML's
> SVG as "a research plan".

yes

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080806/9112e5ea/attachment.sig>