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

List:       kde-core-devel
Subject:    Re: Speed issues on app load
From:       Dirk Mueller <mueller () kde ! org>
Date:       2000-12-21 10:01:41
[Download RAW message or body]

On Mit, 20 Dez 2000, rik@kde.org wrote:

> > Huh???? Do you use the libXft by accident ?
> I use it on purpose :) Loads of debug info and it opens every font,
> but if you delete all your fonts it works well ;)

Yeah, client side font rendering, what else do I need to say ?

> > Konsole is still a special evil case as it does a huge amount of useless and
> > timeconsuming stuff during startup. 
> Yes, I know about konsole :) But all other KDE apps have the same
> trouble. See my timings for keditbookmarks. 7s extra when it hasn't
> been used for a while. This makes me think it's Linux, not KDE. I can
> cope with waiting 2s for an app to start. It's annoying, but it's
> acceptable. 9s is just silly. By that time I've started doing something
> else.

Well, I can reproduce waiting for about 2 seconds. 9 seconds is too
long. are you sure that it spends most of the time in the symbol resolving ?
sounds like serious memory trashing..

> With an optimised build (--disable-debug) it's < 1s to open a new
> window, which is almost usable. Sadly the menu is left visible but not
> repainted while this happens, so it's quite ugly. It would be nice if
> QPopupMenu was able to wait until the menu had closed before emitting
> the 'activated' signal, for non-checkable items anyway.

Yes. This used to work, no idea why it broke, bit it looks damn ugly now. 
I guess it never really worked by definition as X is full async so there is
no way to know when the repaint happened...


Dirk

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