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

List:       kde-core-devel
Subject:    Re: KFontCombo speed
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-07-24 20:55:10
[Download RAW message or body]

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

After about 5 minutes of scrolling up and down, all fonts are rendered
and it is fast :}

> 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?)

The usual method is to fake it by starting a QTimer in the ctor,
connected to a slot 'processOneItem'. When one item is finished, start
the timer again.

I fear that this will simply cause the application to feel sluggish
for the first few (5-30) seconds, as generating one of the preview
pixmaps seems to take quite a long time (I guess about 100ms on this
Celery 600)

If generating one preview took only 5ms, then it would be OK to do
this in the 'background'.

Of course, if we move to qt-mt for KDE 3, then this sort of thing
can be done in a thread. I would say low-priority thread, but Qt's
thread API doesn't support that :(

Rik

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