QTreeWidget is too laggy during simple item hover (2-3 elements, 3 columns)
-
I am having a problem with a QTreeWidget, namely, when hovering over its items it gets laggy and the UI thread goes to 100% CPU usage as you can see in this video demonstration. The weird thing is, that I had only 2-3 elements in the tree widget. My CPU is old (I7-2600k), but it shouldn't choke on such a trivial task. The lag and high CPU usage occur even if the application is started without visual studio.
Any ideas what could be wrong? (the QTreeWidget is initialized as its shown on its documentation site, since it was only a test)
-
I am having a problem with a QTreeWidget, namely, when hovering over its items it gets laggy and the UI thread goes to 100% CPU usage as you can see in this video demonstration. The weird thing is, that I had only 2-3 elements in the tree widget. My CPU is old (I7-2600k), but it shouldn't choke on such a trivial task. The lag and high CPU usage occur even if the application is started without visual studio.
Any ideas what could be wrong? (the QTreeWidget is initialized as its shown on its documentation site, since it was only a test)
-
@jsulm
I am using CMake, C++17 and my own statically linked library (pure C++17 & STL). In CMake I only link Qt5::Widgets and Qt5::Charts.I have a worker thread in the statically linked library that constantly pools foreground window title & its executable path with 100ms intervals (std::this_thread::sleep_for(100ms)). If the foreground window changes, the thread invokes a callback (std::function & std::bind) that simply moves (std::move) the data(a couple of string and timestamps) into a std::vector, which didn't happen during the test, since the window didn't change. I've profiled the worker thread as well as tested it on console application and its shouldn't bottleneck anything.
I am reading and writing from/to SQLite db. During the test, I've only queried the DB once, to get the data and no writes were done. The class for the db is also in the library.
Atm. the MainWindow consists of central widget, vertical layout, chart view and the tree widget
I have a chart view that displays stacked bar data. During the test there were only 25 data points.In the entire application I have only 4 signal/slot connections.:
- QStackedBarSeries::clicked
- QStackedBarSeries::doubleClicked -- called twice during the test
- QSystemTrayIcon::activated
- QAction::triggered - quit action added to QSystemTrayIcon
I react on one event, namely, QMainWindow::closeEvent.
So overall, it's a bare bones application since I have just started working on it. -
@jsulm
I am using CMake, C++17 and my own statically linked library (pure C++17 & STL). In CMake I only link Qt5::Widgets and Qt5::Charts.I have a worker thread in the statically linked library that constantly pools foreground window title & its executable path with 100ms intervals (std::this_thread::sleep_for(100ms)). If the foreground window changes, the thread invokes a callback (std::function & std::bind) that simply moves (std::move) the data(a couple of string and timestamps) into a std::vector, which didn't happen during the test, since the window didn't change. I've profiled the worker thread as well as tested it on console application and its shouldn't bottleneck anything.
I am reading and writing from/to SQLite db. During the test, I've only queried the DB once, to get the data and no writes were done. The class for the db is also in the library.
Atm. the MainWindow consists of central widget, vertical layout, chart view and the tree widget
I have a chart view that displays stacked bar data. During the test there were only 25 data points.In the entire application I have only 4 signal/slot connections.:
- QStackedBarSeries::clicked
- QStackedBarSeries::doubleClicked -- called twice during the test
- QSystemTrayIcon::activated
- QAction::triggered - quit action added to QSystemTrayIcon
I react on one event, namely, QMainWindow::closeEvent.
So overall, it's a bare bones application since I have just started working on it. -
I've tried it with most of my stuff disabled (worker thread, SQLite db and chart), but no change. I am downloading QT debug info, so I can pinpoint the problem, since without the symbols, it only shows that QApplication::exec() has 99% of the accounted samples. Unfortunately the downloading will take a while.
-
I've tried it with most of my stuff disabled (worker thread, SQLite db and chart), but no change. I am downloading QT debug info, so I can pinpoint the problem, since without the symbols, it only shows that QApplication::exec() has 99% of the accounted samples. Unfortunately the downloading will take a while.
-
@jsulm Just created a fresh app with QTreeWidget and 5 random elements, and it seems to be working fine (UI thread usage ~10%-20% during hovering)
@SGaist
hey,
I am using 5.13, but I have also tried changing Qt path in CMake to 5.12, same result.
Windows 10 Pro, 1903
GammaRay is compiling as we speak. Will definitely give it a try. -
Found the culprit. I was still using an old db data which had a lot of data from initial library test. The initial string values were not shrunk and had a bunch of null terminating characters at the end (since I had to pre-allocate buffer that was passed to C-style WinAPI functions). After adding Qt source and debug symbol the culprit was obvious.
Basically, QTextEngine::shape was indirectly calling NtGdiGetCharWidthW that was choking on ~1k null terminating characters per string.
Didn't thought of that before, because I knew the strings were shrunk, but I guess a lot of not optimized data from the first tests were still in db.
Thank you guys for help, have a lovely day.
