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

List:       kde-core-devel
Subject:    Re: Colors - Performance impact of non-equal inactive and active
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2007-12-03 20:08:48
Message-ID: 13ed09c00712031208x562a97fha6cb68f9f5e83fbb () mail ! gmail ! com
[Download RAW message or body]

> Huh? Why does accessing the menu make Konsole go inactive?

Firstly, let me clarify that I am referring to Konsole's main menu
here.  I don't know the reason, but you can see with QT_FLUSH_PAINT or
using trace statements in gdb that activating one of the menu items
causes all the other widgets in the window (including the terminal
display area) to be repainted.

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

When a widget receives a WindowActivate or WindowDeactivate event it
will also send that event to all of its children, which will cause
them to repaint if their inactive and active palettes are not equal,
and then send a WindowActivate / WindowDeactivate event in turn to all
of their children.  This process repeats recursively down to the leaf
widgets.

> (* What I /would/ be OK with is making it default-off only on "slow"
> computers...)

I expect that repainting an entire window (especially large,
full-screen windows) will cause a perceptible performance impact on
virtually all PCs.

Looking at this as a simple cost vs. benefit analysis, I agree with
Aaron that I don't think the somewhat subtle effect is worth the
performance hit.  If that problem is fixed, then I don't have any
other objections to including it.

Regards,
Robert.

On 03/12/2007, Aaron J. Seigo <aseigo@kde.org> wrote:
> On Monday 03 December 2007, Matthew Woehlke wrote:
> > (maybe even 'just the selection' if that is possible). But that's Qt 4.4
> > stuff.
>
> well, probably 4.5 at this point unless it gets considered to be a bug fix
> (feature freeze has come and gone iirc) .. but yes, since getting this right
> is probably future qt work, maybe this should be future kde work as well.
>
> as you note, kde3 is the same here so it's not a regression for kde. we can
> and should catch up with others, but i think we have enough other cool stuff
> that this is not a critical feature and it would be a crying shame to have
> such an impact on our performance just to toggle one set of colours. it just
> isn't worth it.
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Trolltech
>
[prev in list] [next in list] [prev in thread] [next in thread]