--nextPart2224587.jLaxshE3YH
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 sti=
ll
> > 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) =3D)

> 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,=
=20
however. it's just something that people tend to skip over when seeing the=
=20
possibility for "more features!" =3D)

and i really don't care about the extra library dependency, as we already u=
se=20
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 le=
ss
> > "!!"). thankfully we wrapped QSvgRenderer in Plasma::SVG so we can inde=
ed
> > do this kind of thing without breaking any SVG usage in Plasma, but sti=
ll
> > .. uck.
>
> I'm open for ideas here.

if there was a similar convenience API to the Webkit SVG renderer as we hav=
e=20
with QSvgRenderer, that would be great. otherwise we'd have to do it oursel=
ves=20
in Plasma::Svg, which means that it at least needs to be possible. the bonu=
s=20
points come from having this functionality in QtWebkit so others can benefi=
t=20
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:=20

 * 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 docum=
ent=20
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

=2D-=20
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


--nextPart2224587.jLaxshE3YH
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkiZ8S4ACgkQ1rcusafx20MJEwCgi+krAasmE8SW2kCTl0vaVkJy
f04AoJrrUhaSBET9gOHLVp0XV2sCAaZe
=lU+f
-----END PGP SIGNATURE-----

--nextPart2224587.jLaxshE3YH--