https://bugs.kde.org/show_bug.cgi?id=453534
Ben Scherrey <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- Ever confirmed|0 |1 CC| |[email protected] --- Comment #26 from Ben Scherrey <[email protected]> --- A fix is up for review as merge request !229: https://invent.kde.org/utilities/kcalc/-/merge_requests/229 Fix 100% CPU usage from resizeEvent feedback loop under fractional scaling This issue has been plaguing me for a couple of years now and I thought it would just show up fixed one day. So this week I decided to take a look and found out why it hasn't. Understandable. Hopefully this will be accepted as a simple one-liner that can't break any future versions and us old people can continue to use the super convenient kcalc! I've been a KDE user since it and Qt were first released. Thanks. KCalculator::resizeEvent() forces the window to minimumSize() whenever the current size is smaller, by calling resize(). That resize() delivers another resizeEvent, which re-runs the same check. size() and minimumSize() are integer QSizes. Under fractional display scaling (I'm running at 150% on X11: KCalc 22.12.3, Qt 5.15.8, KF5 5.103.0, Plasma/KWin 5.27.5, kernel 6.12.43+deb12-amd64, Debian 12 "bookworm") Qt rounds scaled geometry to whole device pixels, and the rounded minimumSize() and the rounded realized window size can differ by one pixel. The exact "<" comparison therefore stays true on every pass, so the window resizes itself in a tight loop and pins a CPU core for as long as KCalc is open. At integer scaling (100%/200%) the two values are equal after one pass and the loop never starts, which is why this reads as WORKSFORME for anyone on Wayland, integer scaling, or the Qt6 high-DPI path. Only force a resize when the shortfall exceeds the rounding error (4px). This breaks the loop on every scale factor while preserving the existing workaround that grows the window to fit its content after restoring from a maximized state (added in 6ff969e3 / d5ae89b8); those size differences are far larger than the tolerance. Verified on the 22.12 branch (the master Qt6 build was unavailable on my test machine; the resizeEvent logic is identical): per-second CPU of the kcalc process went from a sustained 95-97% of one core to a flat 0% from the first second, with normal sizing intact. -- You are receiving this mail because: You are watching all bug changes.
