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

[Matthew Woehlke]

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

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

Ouch :-(.

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

> 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" 
computers...)

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

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, 
incidentally).

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

-- 
Matthew
<punchline removed due to distasteful content>