Bug 442465

SUMMARY
Creating a QProxyStyle and setting it to a widget creates a Breeze::Style, installing event filters on QApplication and slowing down application events, more so as you create hundreds or thousands of QProxyStyle. I'm not sure if this is a bug or by design.

STEPS TO REPRODUCE
1. Clone and run https://github.com/nyanpasu64/qproxystyle-lag.
2. Click "Open file dialog" and notice it's quick to open and close.
3. Click "Generate lag" and wait for the app to finish creating 2048 QSlider with QProxyStyle.

OBSERVED RESULT

At some point after connecting QProxyStyle to QSlider (I think when QSlider layouts), QSlider calls QProxyStylePrivate::ensureBaseStyle()[1], which calls QStyleFactory::create(QString const&), and qLoadPlugin<QStyle, QStylePlugin>. As a result, each QProxyStyle constructs a separate instance of Breeze::Style.

[1]: https://invent.kde.org/qt/qt/qtbase/-/blob/kde/5.15/src/widgets/styles/qproxystyle.cpp#L78

Each Breeze::Style constructed installs two app-wide event filters (QApplication::installEventFilter()), one from Breeze::WindowManager::WindowManager(), and one from Breeze::Mnemonics::setMode().

After "Generate lag" completes, "Open file dialog" takes a long time to open or close (spending time in QCoreApplicationPrivate::sendThroughApplicationEventFilters()), and the app remains unresponsive for a second after the dialog closes (spending time in Breeze::ToolsAreaManager::configUpdated()).

If you click "Delete widgets", all QWidget are deleted, and the dialog opens and closes quickly (no more waiting in QCoreApplicationPrivate::sendThroughApplicationEventFilters()), but the main window remains unresponsive after closing the dialog (waiting in Breeze::ToolsAreaManager::configUpdated()).

If you click "Delete styles", the opposite happens.

EXPECTED RESULT

Commenting out `custom->setStyle(style);` (creating 2048 QSlider and 2048 QProxyStyle, but leaving the QProxyStyle unused) makes "Generate lag" complete instantly (since QProxyStylePrivate::ensureBaseStyle() is never called), and fixes the "Open file dialog" lag entirely.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.22.5 (both Breeze 5.22.5 and master)
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.2-zen1-2-zen (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2

ADDITIONAL INFORMATION

I'm not sure if this is a Qt bug (each QProxyStyle constructing an independent QStyle instead of reusing QStyle by name), a Breeze bug (each Breeze::Style slowing down the application by a tiny bit), or an application bug (it's the responsibility of the app to not create thousands of QProxyStyle, even though thousands of QWidget doesn't cause an analogous slowdown).

I'm not sure how to address this. Maybe the Breeze::Style instances could coordinate to not install O(n) event filters and spend O(n) time responding to config changes? And if Breeze::Style is stateless, maybe the instances could share their internals?

I don't think Breeze can return the same Breeze::Style heap allocation for multiple QProxyStyle, because QStyleFactory::create() is supposed to return a unique pointer. You'd have to change Qt, not Breeze, to get QProxyStyle to reuse underlying styles. And this wouldn't fix applications which don't use QProxyStyle, but call QStyleFactory::create() themselves to generate hundreds or thousands of QStyle objects.