Colors - Performance impact of non-equal inactive and active palettes
mw_triad at users.sourceforge.net
Mon Dec 3 17:23:09 GMT 2007
Robert Knight wrote:
> 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
This is the *default*. Whole-palette effects are still available and at
this point it looks like they will be included in our shipped palettes
(don't worry, there is an option to turn them off, i.e. the palette can
define the effects w/o forcing the user to enable them, and yes the
default will be 'no effects').
> 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.
Huh? Why does accessing the menu make Konsole go inactive?
> 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
If Qt is going to be not-smart about repainting widgets (really, I
suppose it can't be, or at least it would be difficult), and if the main
part of Konsole is not using any of the palette anyway, then I would
actually recommend making active and inactive the same. Just because
selection is the only thing that changes *by default* doesn't mean it's
the only thing that will change, ever.
(Whether Konsole should obey state effects, if configured, is a whole
other topic; let's not go there for now.)
> - but this is a
> bad habit and since the palette propagates to child widgets, could
> have unexpected side effects.
Do child widgets repaint because the top-level widget repaints, even if
they don't need to (i.e. active and inactive palettes for just that
> 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.
It's the InactiveText foreground role in the Selection set; it has
nothing to do with active/inactive state. It may not be used by much
outside of katepart yet. It's there because my experience is that it's
hard to find a color for InactiveText that works with Selection and the
other sets, so this one is "special" among the extended roles in having
Selection treated specially.
I don't overly mind adding an option to turn off distinguishing active
and inactive selection, but I would strongly disagree with making it
off-by-default*. Apple HIG requires it on, Windows is moving that way,
and GTK (and even non-GTK/KDE X applications!) has been that way for
some time... KDE3 stands out as the exception to the direction all other
desktops are moving or have already moved.
(* What I /would/ be OK with is making it default-off only on "slow"
> 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.
Hmm? The only reason this would *not* affect Qt4 applications is that I
don't think we export our palette yet (which is a bug/missing feature,
> Does anyone know how Qt solves the problem on the Mac?
Good question, especially with the other comments (other desktops
dealing with this already). It feels like Qt is playing catch-up :-(.
Looking at GTK might be interesting.
One solution I suppose is to check if only selection colors differ, and
add a repaint hint if any difference should cause a repaint, or if
selection-only differences should only repaint things with selections
(maybe even 'just the selection' if that is possible). But that's Qt 4.4
<punchline removed due to distasteful content>
More information about the kde-core-devel