Colors - Performance impact of non-equal inactive and active palettes

Robert Knight robertknight at
Sat Dec 1 06:01:31 GMT 2007


There has already been some discussion of the performance problems
[1][2] caused by having inactive and active colour palettes for
widgets which are different.  I couldn't find a more recent discussion
on the matter - please point me to it if there is one.

At the time of the original discussion, the whole window changed
appearance when changing between the inactive and active palettes, so
the performance problems were very evident.  Fast forward to November
and the only difference between the inactive and active colour
palettes is the colours used for selected items (
QPalette::highlight() and QPalette::highlightedText() ).  This effect
is quite subtle, without such obvious flicker, but the problem of Qt
repainting the entire widget whenever its active/inactive status

In QWidget::event() , Qt simply compares the inactive and active
palettes on a WindowActivated or WindowDeactivated event and triggers
a complete repaint if they are different.  This applies to many, many
widgets which look identical whether they are active or inactive
because they don't make use of the highlight colour, or only make
limited use of it under certain circumstances (eg. part of the widget
is an active selection).

On some computers, this problem merely makes applications feel a
little slower than they should do, since it completely negates the
performance benefit which Qt 4's double buffering provides when
switching between windows.  On others (older computers, thin clients
or any other situation involving X over a network) I guess it may
render applications very uncomfortable to use.

Konsole's terminal display is one such widget which doesn't use the
highlight colour, and since its content consists entirely of text, a
full update of a large Konsole window full of content is expensive.
Currently a full update occurs because of the inactive/active switch
every time the menu is accessed.  I am not sure what the 'correct'
solution is.  One option is for Konsole to scan the palette and "fix"
it so the inactive and active colours are all the same - but this is a
bad habit and since the palette propagates to child widgets, could
have unexpected side effects.  Does anyone know how Qt solves the
problem on the Mac?   Any ideas for a better solution in a short-time

A more general problem is that I couldn't figure out how to make the
inactive and active palettes the same using the colours KCM module.
There is a colour labelled "Selected text inactive" in the list which
looks like the highlight colour, but changing it has no effect.  The
vast majority of users who have sufficiently slow computers that they
can"feel" the performance difference will not be aware that the colour
scheme is the problem, only that KDE 4 doesn't feel as fast as other
modern Qt applications (3 or 4) they use.



More information about the kde-core-devel mailing list