I just started learning Kdenlive and I noticed something strange. I am using Debian 8.7 and an Appimage of Kdelive Version 16.12.2. When I run Kdenlive from the Appimage I see unexpected CPU usage in idle. I've found out that if I do the following steps it stops: -If I press play and then pause (with or without any videos inside the project) with the Clip Monitor Tab selected, the CPU usage returns back to normal. -If I do anything in Kdenlive (like selecting the Project Monitor Tab) the CPU usage rises again. In order to stop it I have to select the Clip Monitor Tab and press play and pause again (the CPU usage stops only after pressing pause).
Additional info: I think the bug has to do with the sound settings. By default the Kdenlive Appimage comes configured with "Audio driver: Automatic". If I set it to "Audio driver: OSS" I see significantly less CPU usage. Logically it shouldn't have any CPU usage on a newly started project that has no files in it (why process sound that isn't there?). Another thought that crossed my mind is that it may be pulseaudio that is the problem. I've read many cases on the internet (with various programs) about pulseaudio using CPU excessively.
Additional info: As I suspected, the problem is most likely related to pulseaudio. Searching for a solution I stumbled across some bug reports on various distros that suggested to try inserting the following line to /etc/pulse/default.pa : load-module module-udev-detect tsched = 0 This indeed fixed the problem. But it messes up gnome sound so I can't use this solution. To my understanding the issue has to do with some problems in the alsa drivers and pulseaudio scheduler. Debian 8 uses an old version of pulseaudio and Debian 9 is just around the corner. Maybe the bug is fixed in the newer versions of pulseaudio. So, I don't know if this is actually a Kdenlive bug.
Additional info: I've just updated to Debian 9. Unfortunately the problem is still here. I was hopping that with a new clean install (and updated software) that the problem will go away. I have tested the Appimage version 17.04.1b on a clean Debian 9 fresh installation without changing anything. When I first run Kdenlive the CPU usage goes to 30%. That is with the Audio driver setting set to Automatic. If I change it to PulseAudio the CPU drops to 10%. If I add a video file the CPU usage raises up a bit. Without the video playing and without adding any filters or effects. And if I close Kdenlive completely the CPU usage returns to normal. I have also noticed that if I open the settings window (Settings > Configure Kdenlive) the CPU usage returns to normal. In fact if the focus is anywhere else than the main window of Kdenlive (for ex. in a Nautilus window) the problem goes away. If I click back to the main Kdenlive window to give it the focus then the problem is back. (Except with the Audio driver setting set to Automatic. In that case the CPU remains high).
Created attachment 107949 [details] CPU usage Giving focus to the main window increases the CPU usage.
Created attachment 107950 [details] CPU usage
Additional info: I've just tried kdenlive-alpha1-17.12 AppImage (In the About window says: version 17.11.70) and I see the same behavior. Giving focus to the main window increases the CPU usage. Giving focus anywhere else (even on another Kdenlive window), the CPU returns to normal. Does anyone else see this behavior?
Yes, using version fdbbf2127 I see the same behavior. As long as the main window is active, I have constant 25% CPU usage.
I can confirm the issue. Wondering if that could be related to the Qt version (5.7.0) used for the build.. I am investigating...
I can confirm the issue. Wondering if that could be related to the Qt version (5.7.0) used for the build. My main build using Qt 5.7.1 does not have this problem. I am investigating...
Comment #7 was using Qt 5.9.1.
Confirmed, issue in KDE Frameworks, patch pending: https://phabricator.kde.org/D7954
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 365050 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 365050 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
*** Bug 386773 has been marked as a duplicate of this bug. ***
*** Bug 386919 has been marked as a duplicate of this bug. ***