| Summary: | KToolBar constant repaint when a QToolButton is added in it | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kxmlgui | Reporter: | Jean-Baptiste Mardelle <jb> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | simonandric5 |
| Priority: | NOR | ||
| Version: | 5.23.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kwidgetsaddons/c6191993c7e5ea4873f0635a6fac79773c9cb96c | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | Fix repaint loop | ||
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...
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 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 |
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