Bug 365050 - KToolBar constant repaint when a QToolButton is added in it
Summary: KToolBar constant repaint when a QToolButton is added in it
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kxmlgui
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.23.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-03 21:32 UTC by Jean-Baptiste Mardelle
Modified: 2017-10-07 16:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Fix repaint loop (880 bytes, patch)
2016-07-10 20:32 UTC, Jean-Baptiste Mardelle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Mardelle 2016-07-03 21:32:59 UTC
While investigating a major CPU usage in Kdenlive, I could trace it to KToolBar.
Adding a QToolButton in a KToolBar causes a constant repaint of the toolbutton with a big CPU consumption (1-2% for just one toolbutton). The same code with a QToolBar works correctly.

Reproducible: Always

Steps to Reproduce:
This sample code can reproduce the issue:

QToolButton *button = new QToolButton();
QAction *ac = new QAction(QString("test"), this);
button->setDefaultAction(ac);
KToolBar *tb = new KToolBar(this);
addToolBar(tb);
ktb->addWidget(button);

Actual Results:  
You can visualize the problem using KWin's "Show Paint" Desktop Effect which shows the toolbutton is contantly repainted, and CPU usage also goes up (1-2% on my Core i7) whenever the app window is active.

Expected Results:  
No useless repaint / CPU waste. Replacing KToolBar with QToolBar fixes the problem.

Also tested against latest 5.24 Frameworks
Comment 1 Jean-Baptiste Mardelle 2016-07-10 20:32:42 UTC
Created attachment 99993 [details]
Fix repaint loop

After some investigation, I found the line responsible for the endless repaint loop of QToolButtons in KToolBar (line 1359).

It looks like this line is changing the text of the button inside the paint event, thus creating an endless repaint loop with the side effects described in my original report. This code seems to be quite old, but it definitely creates a repaint loop!

My patch is just a workaround disabling the problematic line, someone with a better understanding of the code should have a closer look...
Comment 2 Jean-Baptiste Mardelle 2017-10-06 06:10:21 UTC
Git commit ba889143d684326f0b8b1988ea12073c95cc8ffe by Jean-Baptiste Mardelle.
Committed on 06/10/2017 at 06:07.
Pushed by mardelle into branch 'master'.

Fix KToolBar repaint loop
Related: bug 377859
Differential Revision: https://phabricator.kde.org/D7954

M  +10   -4    src/ktoolbar.cpp

https://commits.kde.org/kxmlgui/ba889143d684326f0b8b1988ea12073c95cc8ffe
Comment 3 David Faure 2017-10-07 16:29:16 UTC
Git commit c6191993c7e5ea4873f0635a6fac79773c9cb96c by David Faure.
Committed on 07/10/2017 at 16:29.
Pushed by dfaure into branch 'master'.

KAcceleratorManager: set icon text on actions to remove CJK markers

Summary:
This replaces the KToolBar event filter hack to solve the same issue:
when an action text appears in a menu we want the & accelerator, while in
toolbars wewant that removed. Qt takes care of it, except for the more tricky
case of CJK markers: "<chinese here> (&O)" where &O exists only to get an ascii
accelerator.
Instead of hacking the text at painting time (!) it's much more robust to
remove " (&O)" from action texts and sett hat as the icon text upfront.

With this in, we can remove the KToolBar hack which leads to endless repaints.
Related: bug 377859

Test Plan: Unittest

Reviewers: mardelle, ilic, sandsmark

Subscribers: #frameworks

Differential Revision: https://phabricator.kde.org/D7964

M  +31   -6    autotests/kacceleratormanagertest.cpp
M  +1    -0    src/CMakeLists.txt
A  +106  -0    src/common_helpers.cpp     [License: LGPL (v2+)]
A  +46   -0    src/common_helpers_p.h     [License: LGPL (v2+)]
M  +21   -0    src/kacceleratormanager.cpp

https://commits.kde.org/kwidgetsaddons/c6191993c7e5ea4873f0635a6fac79773c9cb96c