[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 20:39:12
[Download RAW message or body]

On Wednesday 13 November 2002 18:38, Vadim Plessky wrote:
> ...
> |  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.
>
> Indeed.
> And current icon effects ('gray', 'gamma', etc.) are somewhat ugly.
> I think simple effect of setting transparency for a whole object to 0.5
> (from 1.0) would be nice.

Custom SVG additions to be applied to icons before rendering would be perfect. 
Think of color remapping (I want me arrows yellow!) to filter effects (I need 
bump mapped icons!) and perhaps even animation (gray to color blending 
with rotation animation on mouse hover).

> |  And I don't think that hardware accelaration in SVG drawing will bring
> | the speedup for 16x16 icons ;-)
>
> Hardware acceleration would speed up *everything*.
> I think th eonly limit would be file access speed, so may be you would want
> to inline all icons in source code, or pre-fetch (parsed) SVG file.

I don't think GPU acceleration will help in XML parsing. And acceleration of 
the drawing of 4 points for a small detail in a 16x16 icon is not really 
stunning.


> |  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!).
>
> AFAIK QPainter doesn't have all necessary functionality to support SVG.

But AFAIK, Xc has nothing to do with SVG. It only exports all the 
functionality of XRender together with doing everything in software when 
XRender is not available.

> So, most likely you want to test VPainter (check Karbon14 code in KOffice)
> Currently it uses libart (rendering is done in software).
> It can be that VPainter would be ported to Xr/Xc in the future.
>
> as about Xr/Xc in general: API should stabilize first.
> And someone should try to patch Qt & catch possible bugs.
> You may want to try snapshots of Xr and Xc from here:
>         http://keithp.com/~cworth/download/xsvg-20021104.tar.gz
>         http://keithp.com/~cworth/download/XrXc-20021104.tar.gz
> It's just 33K+65K tarballs, there is no huge rependencies.

I already had a look at the code. But couldn't compile...

> ...
> You mean, icon previews/thumbnails?

No. Plain mime type icons.

> ...
> |  > 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]
>
> You can optimize libraries even without profiler.
> If you reduce rendeirng time for SVG from 1 sec. to 0.01 sec., most  likely
> you will get speedup in rendering of folder in Icon View mode, by similiar
> spedup factor.

SVG rendering speed is unimportant if all icons are already prerendered in a 
cache pixmap. It's the same as with a KDE startup directly after you switched 
on your computer or after a logout/login.

And you can't know exactly what's happening on Konqueror startup even if you 
had written 20% of the code executed on startup, unless you really check.
E.g. it's useless to look for optimizing SVG rendering if it only takes 0.1% 
of the Konqueror startup.

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]