[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: svg crystal?
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2002-11-13 15:29:02
[Download RAW message or body]

On Wednesday 13 November 2002 10:54, Vadim Plessky wrote:
> On Wednesday 13 November 2002 3:59 am, Maks Orlovich wrote:
> |  Vadim Plessky wrote:
> |  > On Tuesday 12 November 2002 10:46 pm, Nikolas Zimmermann wrote:
> |  > |  On Tuesday 12 November 2002 18:25, Nicolas Goutte wrote:
> |  > |  > As far as I know, the base for Crystal are SVG pictures. But KDE
> |  > |  > still can nly use PNG icons.
> |  > |  >
> |  > |  > Have a nice day/evening/night!
> |  > |
> |  > |  No, we can also render SVGs since quite some months :)
> |  > |  We prerender the icons and commit the generated ones, for
> |  > |  speed reasons. (PNG loading is faster than SVG rendering...).
> |  >
> |  > I believe it's possible to reduce this gap.
> |  > I don't know what is typical time to load PNG, but good SVG icon can
> |  > be rendered in less than 0.5 sec.
> |
> |  Which means it's unusable, as you need to load about 5-10 icons per a
> | menu, not to mention the toolbars. I *hope* you're wrong.
>
> Sorry, I has been mistaken by factor of 10x.
>
> [vad@VPlessky Blue-Sphere]$ test-performance arrow-right.svg
> File 'arrow-right.svg'
> Scaling took 0.061831(s)
> [vad@VPlessky Blue-Sphere]$ test-performance arrow-right.svg
> File 'arrow-right.svg'
> Scaling took 0.0620885(s)

Hi,

I don't think online rendering to be much of a issue. There always should be 
something like a persistant icon cache (even with lazy icon loading...).
This should be a (few) big shared pixmap(s) on the X11 server where 
applications could blit the needed icons from. And for applications to 
quickly recognize this on startup, there should be something like a ksycoca 
mappable database. I would say another job for a KDED daemon.

Even for .png you have to apply icon effects. A nice thing of SVG is that 
these icon effects could be simple added to the DOM before rendering.

And I don't think that hardware accelaration in SVG drawing will bring the 
speedup for 16x16 icons ;-)

Aside from that, if I start konqueror as file manager showing my home, it WILL 
need >40 icons from the beginning.

You know, I'm very interested in benchmarks when QT will use Xc for QPainter 
on X11, together with hardware acceleration (Yeah, anti-alised 
blended/transparent widgets even for X11 servers not supporting XRender!).

Josef

> So, you will get rendered 15 icons (required by KMail, or 14 icons for
> Konq) in about 0.9 sec.  (and this implementation is in *software*,
> hardware-assited rendering canbe faster by a factor of 100x)
> Which is *ok*, as Konq's startup time is about 3 sec., and Kmail starts
> even slower.

What about the icons of the icon view in file manager mode?

> If KSVG renders slower than this - KSVG should be fixed. No point to blaim
> SVG standard here.
> Besides:  I believe non-XML SVG drawings (SVG-like data structure) can be
> rendered even faster, as such format doesn't require parsing XML and
> building DOM tree.
>
> |  For perspective In startup times, we're talking about times in
> | milliseconds being something to be eliminated. And before demand-load,
> | the time to load PNG icons was unaccpetable - roughly a quarter of
> | startup time for app like Konqueror. And a non-trivial portion of that
> | concerns image->pixmap conversions, too. (Althugh granted, a lot is in
> | libpng, and disk I/O).
>
> You mean, decompressing zip'ed PNG image into pixmap?
> Does libpng/qt use MMX (or 3DNow, or SSE) instructions to speed up this
> process?

Speculating about the times special code parts take is almost useless.
You have to do benchmarks and profiles. I would suggest using oprofile to get 
the big picture for a konqueror startup. Inclusive kernel time, IPC to 
dcopserver and kio slaves, X11 time needed and so on...

If you want a nice GUI for oprofile, you will need to wait for the newest 
version of KCachegrind supporting views to your whole system ;-)
[I was joking]

Josef



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]