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

List:       kde-devel
Subject:    Re: svg crystal?
From:       Maks Orlovich <mo002j () mail ! rochester ! edu>
Date:       2002-11-13 17:01:09
[Download RAW message or body]

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

The problem is in the IPC needed to coordinate all this. I think Waldo did a
prototype of an icon server, though.. But the thing is, with png icons and
lazy loading icon loading time really doesn't seem much of an issue. Now if
we could somehow lazy-load the Xft/fontconfig indeces, and lazy-create all
those darn dozens of widgets each toolbar creates...

> ksycoca mappable database. I would say another job for a KDED daemon.

Certainly, making read-only mmap'd data avilable would make sense. The
problem is, there are lots and lots of icons - which ones does one load,
and how does one communicate about loading some others? 

DCOP doesn't seem to be a good choice - I don't know about the typical
latency, but for i.e. Konqui broadcasting to other copies of itself about a
new history entry took something like 12ms*number of processes here. 

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

Yeah, but the icon effect code is there, and works, so it's not much of an
advantage, I think..

> And I don't think that hardware accelaration in SVG drawing will bring the
> Aside from that, if I start konqueror as file manager showing my home, it
> WILL need >40 icons from the beginning.

Yeah, in fact Konqueror listing my home dir - 1192 files - spends a
considerable amount of time just checking for icons in the cache. Don't
remember the number off top of my head, but it was in the order of seconds.
And i.e. the changes to the fingerprint function I made cut out quite a bit
of time for that. 

> Speculating about the times special code parts take is almost useless.
> You have to do benchmarks and profiles. 

I am basing my observations on about a month worth of manual intrumentations
using cycle counters. Painful, but gives a nice overfiew of what's going
on. 

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

I wouldn't.. Last time I checked, oprofile produces flat profiles, which in
my experience are nearly useless in this case - i.e. unreadable. The top
few entries are in single percentage points, and are generic datastructure
stuff, plus malloc and co (oprofile was great for optimizing Keramik,
however, since on a stress benchmark the code paths are much simpler). It
just doesn't give much of an idea on what top-level parts of the code are
spending the time - but rather then what leaves are. I mean, for instance
that fingerprint example - the inefficiency was in doing too many string
concatenations, too often.. But a QString::operator+ or such entry doesn't
help much to figure out where the problem is - while going "OMG, we spend
30ms in KIconEffect::fingerPrint doing string ops" does.

KCacheGrind, on other hand, rocks, thanks a lot for it; really helps get an
overview of the processing. It really is a giant step forward for trying to
get things nice and fast. (Although obviously, there are precision
limitations due to simulation). BTW, what's its strategy for handling
syscalls timings? That seems like the hardest thing to measure right due to
simulated->real CPU switch..

Thanks,
Maksim

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