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

List:       kde-devel
Subject:    Re: svg crystal?
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-11-13 9:44:29
[Download RAW message or body]

On Wednesday 13 November 2002 10:22 am, Roger Larsson wrote:
|  On onsdagen den 13 november 2002 01.59, 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.
|  >
|  > 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).
|
|  As I read it above it caches the icons in X drawable form (pixmaps)?

librsvg2 is using gdk-pixbufs (pls do not mix it with GTK) to 
dispaly/store/process images.
I think gdk-pixbuf has caching for those pixbufs.  Some demos which I have 
seen look like pretty nice (fast animations, etc.).

Carl started coding libsvg/sxvg using librsvg as a reference, but finally it 
became another library (not depending on gdk-pixbuf, Pango, etc.).  I think 
caching, in some way, is implemented/present in it.
But it can be that for hardware-accelerated implementation this is not 
extremly important (GPU will do rendering faster than you can fetch image 
from memory)

|
|  It looks like #3 is the way used, then SVGs could become the future winner
| (as icon sizes move upwards). Small space requirements as cached but still
| accelerated drawing (if X gets accelerated SVG drawing).

Carl Worth's work is exactly to accelerate drawing (rendering) in X.
SVG was just *good enough* example, and some people were attracted by 
PostScript-like drawing API in Xr.

|
|  /RogerL


-- 

Vadim Plessky
SVG Icons
http://svgicons.sourceforge.net
My KDE page
http://kde2.newmail.ru  (English)
KDE mini-Themes
http://kde2.newmail.ru/themes/


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