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

List:       kde-core-devel
Subject:    Re: KFontCombo speed
From:       Thomas Zander <zander () planescape ! com>
Date:       2001-07-25 6:43:35
[Download RAW message or body]


On Tue, Jul 24, 2001 at 09:55:10PM +0100, Rik Hemsley wrote:
> #if Martijn Klingens
> > On Tuesday 24 July 2001 16:53, Rik Hemsley wrote:
> > > Anyone have an idea how to work around the sluggishness ?
> > 
> > Does it paint only what is visible, or does it preprocess all entries upon 
> > initializing?
> 
> It paints only what is visible, so if you scroll then it blocks while
> it renders the strings for the currently visible section.

The thing I noticed is the first opening takes quite some extra time, my
pointer actually freezes some seconds.

I think rendering the first 10 would do the trick, though I am wondering why
the first took so long, is it because a font list is read, and that takes
so long? (even on my P3/900)

> > I think the best would be to setup the entire combo in the background
> > while the app is idle, but only load initially what is actually
> > visible. That is, the constructor doesn't generate any preview and
> > upon drop down only the visible entries are immediately processed. The
> > lazy loading of the remaining entries can be done directly after the
> > constructor, as long as that is marked as an idle-time event (how does
> > one do that in Qt btw?)

Hmm, KWord uses a timer for background rendering, David can probably give
you pointers on how this is done, it works very well there!

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

[Attachment #3 (application/pgp-signature)]

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