https://bugs.kde.org/show_bug.cgi?id=481003
Jakob Petsovits <jpe...@petsovits.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas
|ma/powerdevil/-/commit/0338 |ma/powerdevil/-/commit/1017
|25d2217ec3c91af5af1fc0a6fbb |585fe5ef2263e02e6dc6f5227de
|66f91fdbd |15fb3ba5d
--- Comment #6 from Jakob Petsovits <jpe...@petsovits.com> ---
Git commit 1017585fe5ef2263e02e6dc6f5227de15fb3ba5d by Jakob Petsovits.
Committed on 22/06/2024 at 12:16.
Pushed by jpetso into branch 'Plasma/6.1'.
daemon: Limit KAuth backlighthelper calls to only one at a time
KAuth invocations are slower than users can move a slider.
So we get many brightness change requests, and KAuth can't keep up.
As a result, high-frequency brightness change requests for
BacklightBrightness (i.e. laptop displays) would feel very laggy
and get worse over time if not given a break to catch up.
This commit fixes the lagginess. Conceptually it's easy:
Don't start a new KAuth helper job until the current one has
reported a result. At that point, check if a different brightness
level was requested in the meantime, and start another job only then.
BacklightHelper can deal fine with interrupting a running animation
and starting a new one from the current brightness level. Hence,
there is no need to wait until the end of the brightness animation
to start a new KAuth job - this would only increase latency.
Starting the new job right after receiving a result is perfectly fine.
In the same go, we make two related improvements.
Firstly, the udev-powered brightness observer will not only ignore
events when the animation timer is running, but also in between
setBrightness() and the KAuth result handler where the timer
is started.
Secondly, the condition involving m_brightnessAnimationThreshold
is changed to something sensible. It makes no sense to simply
check the current brightness against a constant number (100) to
determine whether the brightness change should be animated.
What I think this meant to do is to ensure that there are enough
brightness steps available to animate. So following this commit,
we will now animate when the difference between the current and
the requested brightness is 100 or more integer steps.
Taken together, laptop brightness slider UX now seems decent.
Related: bug 470106
(cherry picked from commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd)
M +38 -13 daemon/controllers/backlightbrightness.cpp
M +3 -0 daemon/controllers/backlightbrightness.h
https://invent.kde.org/plasma/powerdevil/-/commit/1017585fe5ef2263e02e6dc6f5227de15fb3ba5d
--
You are receiving this mail because:
You are watching all bug changes.
