[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #49 from Brandon Wright --- (In reply to Brandon Wright from comment #48) > Created attachment 180356 [details] > Patch using public API and setting interval to lowest refresh rate on hotplug > > Here's a better patch that might be of appropriate enough quality. This goes > in quickeffect and sets the minimum interval when displays are added to the > QuickSceneEffect. Actually, ignore this one. It's not as smooth for some reason. I can't seem to get the same smoothness as the simple private API patch. I think it's necessary to have access to the private members of QAnimationDriver and/or QUnifiedTimer to fix correctly. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Brandon Wright changed: What|Removed |Added Attachment #180293|0 |1 is obsolete|| --- Comment #48 from Brandon Wright --- Created attachment 180356 --> https://bugs.kde.org/attachment.cgi?id=180356&action=edit Patch using public API and setting interval to lowest refresh rate on hotplug Here's a better patch that might be of appropriate enough quality. This goes in quickeffect and sets the minimum interval when displays are added to the QuickSceneEffect. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #42 from Brandon Wright --- Created attachment 180257 --> https://bugs.kde.org/attachment.cgi?id=180257&action=edit Patch using private API to update scene graph timers when window refreshed I've attached a patch for kwin that uses the private API to update the timers before rendering. This is pretty simple and seems to fix the problem for me. Let's see if it works for anyone else. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #47 from Brandon Wright --- Created attachment 180293 --> https://bugs.kde.org/attachment.cgi?id=180293&action=edit Patch using public API and setting interval to 4ms Here's a patch using the public QAnimationDriver API and using it to set the interval to 16ms by default, then 4ms in workspace.cpp as an example, which makes things smoother. I tried using Workspace::init like you did to set the interval lower than the fastest refresh rate, which would be (100 / fastestRefreshRate), but it just doesn't detect any displays at that point. It probably needs to be done wherever kwin does display hotplugging and/or video mode changes. I also tried doing a singleton instance and running advance on the window update, but this doesn't work right because it accelerates the animation. QDefaultAnimationDriver has access to QUnifiedTimer's private API and can hook the timer update properly, but with what we're given it's not possible to do something like my simpler patch. You could have the animation driver not do timed updates at all and then update on refresh, but I worry that it would break something else--especially if kwin adds other things using QtQuick. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Brandon Wright changed: What|Removed |Added Attachment #180257|0 |1 is obsolete|| --- Comment #46 from Brandon Wright --- Created attachment 180290 --> https://bugs.kde.org/attachment.cgi?id=180290&action=edit Patch using private API to update scene graph timers when window refreshed 2 Update patch for possible null pointer dereference. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #45 from David Edmundson --- >I'm also wondering whether other components using QtQuick would need changes. Most others are fine. If you're using threaded rendering (which is the default) you get a custom animation driver provided by QSGGuiThreadedRenderLoop. It makes use of the quick animation driver being backed by thread-local storage to end up having a custom animation driver per window that gets driven. That remains an option for kwin, but introducing threads always has some risk! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #44 from Brandon Wright --- (In reply to David Edmundson from comment #43) > >The presumably sanctioned alternative is to inherit QAnimationDriver and use > >the install() method, which replaces the global animation driver. > > Yeah, that's what I had in #24, though it seemed that got lost in the next > comment. > > I rebased it and putting a direct myself this time :) > https://invent.kde.org/plasma/kwin/-/commits/work/d_ed/animation_driver > > --- > > I'll test your patch too and see if that is more noticeable for me. Yeah, I only saw the duration patch before. I tried the animation driver one and it causes the animation to not update at all. Because it's installed globally, I'd guess a subclassed animation driver would need a lot of duplicated boilerplate so it reacts similarly enough to QDefaultAnimationTimer to not break things. QUnifiedTimer::updateAnimationTimers is essentially exactly what we needed. It doesn't have any side-effects because it just triggers an early update and then lets the timer get on with its business. It's unfortunate that it's a private API. I'm also wondering whether other components using QtQuick would need changes. Are they using the full render loop or doing a partially custom thing like kwin?. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #43 from David Edmundson --- >The presumably sanctioned alternative is to inherit QAnimationDriver and use >the install() method, which replaces the global animation driver. Yeah, that's what I had in #24, though it seemed that got lost in the next comment. I rebased it and putting a direct myself this time :) https://invent.kde.org/plasma/kwin/-/commits/work/d_ed/animation_driver --- I'll test your patch too and see if that is more noticeable for me. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #41 from Brandon Wright --- Sticking QUnifiedTimer::instance(false)->updateAnimationTimers(); at the beginning of OffscreenQuickView::update() is probably the wanted behavior. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927
--- Comment #39 from Brandon Wright ---
Ok, here's a hacky example of how to fix it:
> diff --git a/src/effect/offscreenquickview.cpp
> b/src/effect/offscreenquickview.cpp
> index 3dc83f9b2e..44ed0e8eae 100644
> --- a/src/effect/offscreenquickview.cpp
> +++ b/src/effect/offscreenquickview.cpp
> @@ -31,10 +31,13 @@
> #include
> #include
> #include // for QMutableEventPoint
> +#include
>
> namespace KWin
> {
>
> +static bool instantiatedTimer = false;
> +
> class Q_DECL_HIDDEN OffscreenQuickView::Private
> {
> public:
> @@ -146,6 +149,13 @@ OffscreenQuickView::OffscreenQuickView(ExportMode
> exportMode, bool alpha)
> d->m_repaintTimer->setSingleShot(true);
> d->m_repaintTimer->setInterval(10);
>
> +if (!instantiatedTimer)
> +{
> +auto timerInstance = QUnifiedTimer::instance();
> +timerInstance->setTimingInterval(1);
> +instantiatedTimer = true;
> +}
> +
> connect(d->m_repaintTimer.get(), &QTimer::timeout, this,
> &OffscreenQuickView::update);
> connect(d->m_renderControl.get(), &QQuickRenderControl::renderRequested,
> this, &OffscreenQuickView::handleRenderRequested);
> connect(d->m_renderControl.get(), &QQuickRenderControl::sceneChanged,
> this, &OffscreenQuickView::handleSceneChanged);
This isn't the best. It's just to show an example that works. It uses private
APIs. The timing interval would need to be set appropriate to the appropriate
time of the fastest refresh rate and the use of a static global would need to
be changed to something else and moved to the actual kwin initialization.
The presumably sanctioned alternative is to inherit QAnimationDriver and use
the install() method, which replaces the global animation driver. This would
need to add its own logic and run the advanceAnimation() method to update the
scene graph. If you wanted it to be driven by the window being refreshed like
Zamundaaa says is supposed to happen, you could hook the refresh signal up and
just call advanceAnimation instead of doing any timers. That might cause
problems if the scene graph stuff is being used elsewhere.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927
--- Comment #40 from Brandon Wright ---
I didn't notice the overload on instance() which lets you keep the current, so
here's a better version using the private API:
> diff --git a/src/effect/offscreenquickview.cpp
> b/src/effect/offscreenquickview.cpp
> index 3dc83f9b2e..f556e3e14f 100644
> --- a/src/effect/offscreenquickview.cpp
> +++ b/src/effect/offscreenquickview.cpp
> @@ -31,6 +31,7 @@
> #include
> #include
> #include // for QMutableEventPoint
> +#include
>
> namespace KWin
> {
> @@ -145,6 +146,7 @@ OffscreenQuickView::OffscreenQuickView(ExportMode
> exportMode, bool alpha)
> d->m_repaintTimer = std::make_unique();
> d->m_repaintTimer->setSingleShot(true);
> d->m_repaintTimer->setInterval(10);
> +QUnifiedTimer::instance(false)->setTimingInterval(1);
>
> connect(d->m_repaintTimer.get(), &QTimer::timeout, this,
> &OffscreenQuickView::update);
> connect(d->m_renderControl.get(), &QQuickRenderControl::renderRequested,
> this, &OffscreenQuickView::handleRenderRequested);
Change the 1 in setTimingInterval to be lower than smallest refresh rate
interval of all available displays.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #38 from Zamundaaa --- hmm right, QQuickRenderControl that we do use doesn't seem to have equivalent logic. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #37 from David Edmundson --- >QSGRenderThread::syncAndRender advances the animation driver every time right >before rendering, afaict that is not throttled below the display refresh rate. KWin won't use that. Kwin *currently at least* only uses the main thread render loop -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #36 from Brandon Wright --- I looked into it further, and most of what Zamundaaa says is correct, except this: > this happens when KWin tells Qt to render the window. The only time that syncAndRender is called is directly from the render loop. The individual sync and render functions called from kwin are not the same thing. The render loop constantly calls syncAndRender, so theoretically it would be constantly updating, but it's not. Eventually, it all just narrows back to that QUnifiedTimer's trigger rate, which continues to be ever unchanging at 16ms. Another thing that confused me: there's two different advance functions, one in QQuickAnimationController which does almost nothing, the other in QAnimationDriver used by syncAndRender still throttles on the timer. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 madness...@proton.me changed: What|Removed |Added CC||madness...@proton.me -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927
--- Comment #35 from Brandon Wright ---
(In reply to Zamundaaa from comment #34)
> There's nothing to be public, this happens when KWin tells Qt to render the
> window.
It definitely says it's supposed to, but that doesn't seem to be true. I traced
the advance function through and it doesn't ever update the actual scene graph.
It finally eventually reaches AnimatorController, which at the lowest level
just calls commit on a job, which in its base class is completely empty, and
doesn't do much in the one derived class:
> void QQuickTransformAnimatorJob::Helper::commit()
> {
> if (!wasChanged || !node)
> return;
>
> QMatrix4x4 m;
> m.translate(dx, dy);
> m.translate(ox, oy);
> m.scale(scale);
> m.rotate(rotation, 0, 0, 1);
> m.translate(-ox, -oy);
> node->setMatrix(m);
>
> wasChanged = false;
> }
>
> void QQuickTransformAnimatorJob::commit()
> {
> if (m_helper)
> m_helper->commit();
>
> }
Then it calls update() to refresh the window. That's it. From the name, advance
is clearly supposed to actually advance something, but it doesn't. So this is
definitely a Qt bug.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #34 from Zamundaaa --- There's nothing to be public, this happens when KWin tells Qt to render the window. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Nate Graham changed: What|Removed |Added CC||zupnikszyd...@gmail.com --- Comment #23 from Nate Graham --- *** Bug 502178 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #25 from Blazer Silving --- (In reply to David Edmundson from comment #24) > Blazer, can you try cherry-picking the commit from: > work/d_ed/animation_driver in kwin. > > I wrote it ages ago, when looking into the same issue, but it all looked the > same to me. You might have a better eye for this sort of thing Thanks for the pointer, I believe it's this commit: https://invent.kde.org/plasma/kwin/-/commit/7fdcfb89cfbb4b54a4715c34449e0d0896278f5a. However it only seems to be a cross-check regarding the kwin animationDuration value when kwinrc changes were made back then, this issue is more related to the timer/tick counter. It didn't seem to make a difference when using unpatched qt6-base. The findings in Brandon Wright's post are spot-on, a legacy kwin tick/timer must be acting up. Inspecting and unifying the timer(s) seems like the best approach so far, but it may be more difficult to test in a debugging session due to the high framerate required to replicate the issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #32 from Zamundaaa --- (In reply to Brandon Wright from comment #22) > I've been trying to investigate this a bit, and here are some findings: > > In qabstractanimation.cpp: > > 1. QUnifiedTimer isn't actually used directly in this case. It's only user, > QDefaultAnimationTimer just pulls in the value for timingInterval whenever > it is instantiated. The timingInterval value of 16 is *never* changed. > > 2. Because the value is never changed, animations using that timer in Qt > will always be 60fps. This is a Qt bug. QSGRenderThread::syncAndRender advances the animation driver every time right before rendering, afaict that is not throttled below the display refresh rate. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #33 from Brandon Wright --- (In reply to Zamundaaa from comment #32) > (In reply to Brandon Wright from comment #22) > > I've been trying to investigate this a bit, and here are some findings: > > > > In qabstractanimation.cpp: > > > > 1. QUnifiedTimer isn't actually used directly in this case. It's only user, > > QDefaultAnimationTimer just pulls in the value for timingInterval whenever > > it is instantiated. The timingInterval value of 16 is *never* changed. > > > > 2. Because the value is never changed, animations using that timer in Qt > > will always be 60fps. This is a Qt bug. > QSGRenderThread::syncAndRender advances the animation driver every time > right before rendering, afaict that is not throttled below the display > refresh rate. I don't think that's public. If it was, you could use your own timer, but for all I can see, it's all encapsulated. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #31 from Brandon Wright --- (In reply to Brandon Wright from comment #30) > (In reply to Blazer Silving from comment #29) > > It's still worth reporting upstream to QT, considering the > > mission-criticality of the value. If I understand, they only need to provide > > a separate public, dynamic timer for QtQuick to utilize, then kwin would > > need to integrate it. > According to https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph.html > there's some way to replace the default animation driver with a custom one > that doesn't run at 60Hz. I'm looking into this. Nope, no go. That just describes what *they* did under the hood. It's all private and hidden. What we need is a simple setTimerInterval for the QQuickWindow class that drills down through three or four private layers of the scene graph and sets that value. Qt seems to desperately not want anyone to change it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #30 from Brandon Wright --- (In reply to Blazer Silving from comment #29) > It's still worth reporting upstream to QT, considering the > mission-criticality of the value. If I understand, they only need to provide > a separate public, dynamic timer for QtQuick to utilize, then kwin would > need to integrate it. According to https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph.html there's some way to replace the default animation driver with a custom one that doesn't run at 60Hz. I'm looking into this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #29 from Blazer Silving --- > If Qt adds a public API to access the timer then kwin could change the timer > step before initiating a window switch effect. > If Qt can't change, this would need a reversion of the use of QtQuick scenes > in kwin, but I don't think they're going to go for that. I can't speak for kwin developers but yes, very highly doubt they'll walk back these Windowheap effects or port to another system. I'm sure this condition can be counted for without a full revert. It's still worth reporting upstream to QT, considering the mission-criticality of the value. If I understand, they only need to provide a separate public, dynamic timer for QtQuick to utilize, then kwin would need to integrate it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #28 from Zamundaaa --- (In reply to Merkurio from comment #27) > At 120Hz, I don't have major issues, but as soon as I switch to 240Hz, the > whole system feels like it's running at 60Hz (I even confirmed this with > Blur Busters). That's definitely not related to this, please open a separate bug report. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Merkurio changed: What|Removed |Added CC||merkurio...@hotmail.com --- Comment #27 from Merkurio --- Is there a way to apply that patch, but explained for complete beginners? I'm using NixOS (which is inherently different due to its declarative nature), but I'm also experiencing this issue with Plasma 6.3 in both X11 and Wayland sessions while using a 4K 240Hz monitor, and I'd like to fix it. At 120Hz, I don't have major issues, but as soon as I switch to 240Hz, the whole system feels like it's running at 60Hz (I even confirmed this with Blur Busters). Interestingly, a clean initial installation worked correctly, but now, after installing everything I need for my system, it's behaving erratically, and I can't take full advantage of my monitor's maximum refresh rate. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #26 from Brandon Wright --- Unfortunately, I don't think this will be fixed. The problem started when kwin switched over to a QtQuick scene for the window switching effects. QtQuick scene animations have only ever operated at 60hz: * Qt is hardcoded with that define to wait 16ms before considering an animation step * That timer is non-public. * The hardcoded value can't change because QtQuick is heavily depended upon in embedded commercial applications, and that timer was deliberately chosen to get low battery and low latency. If Qt adds a public API to access the timer then kwin could change the timer step before initiating a window switch effect. This isn't likely because over QtQuick hasn't ever been tested with higher frame rates due to that hardcoded value. If Qt can't change, this would need a reversion of the use of QtQuick scenes in kwin, but I don't think they're going to go for that. What's happening when X11 becomes smooth after some time is a Qt bug. The timer is accidentally overwritten because they're all pooled and reused, and the timer ends up triggering instantly. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 David Edmundson changed: What|Removed |Added CC||k...@davidedmundson.co.uk --- Comment #24 from David Edmundson --- Blazer, can you try cherry-picking the commit from: work/d_ed/animation_driver in kwin. I wrote it ages ago, when looking into the same issue, but it all looked the same to me. You might have a better eye for this sort of thing -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 John changed: What|Removed |Added CC||ilikef...@waterisgone.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Brandon Wright changed: What|Removed |Added CC||bear...@gmail.com --- Comment #22 from Brandon Wright --- I've been trying to investigate this a bit, and here are some findings: In qabstractanimation.cpp: 1. QUnifiedTimer isn't actually used directly in this case. It's only user, QDefaultAnimationTimer just pulls in the value for timingInterval whenever it is instantiated. The timingInterval value of 16 is *never* changed. 2. Because the value is never changed, animations using that timer in Qt will always be 60fps. This is a Qt bug. 3. With kwin on X11, some actions like the ALT-TAB switcher seem to trigger a change such that kwin doesn't use that unified timer any more. It doesn't alter the timings, it just uses an entirely different timer. On Wayland, this change never occurs, so it's always stuttery. I'm speculating that some component of legacy kwin on X11 is accidentally creating a new animation timer over the top of the original default one. The solution in kwin would then be to change out that original default timer with whatever kwin/X11 is accidentally overwriting it with. That way both X11 and Wayland are smooth. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #21 from Blazer Silving --- Kindly, can we get acknowledgement from someone KDE-side here? A knowledgable dev could know Kwin's role in this timing value, or insight on how this could be handled upstream in QT -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #20 from Orlando Rodriguez --- (In reply to Blazer Silving from comment #19) > The quickest way to test a one-line fix like this is to build a patched > package for your distro, and install it over the system version. > Most offer tools and helpers for this (PKGBUILD for Arch, fedpkg for Fedora, > etc). Generally the package manager will overwrite the patched version on > the next repo update. Even cooler is setting up an isolated container to do > the build, so you don't have to install all the build dependencies on your > main system :) Thank you so much!! I was able to apply the path by using fedpkg (I did not know about it). And for me it works really really well. Now KDE looks just AWESOME!!! Big difference in my desktop machine with 144hz monitors. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #19 from Blazer Silving --- (In reply to n.parkanyi from comment #17) > (In reply to Blazer Silving from comment #16) > > > It looks like these animations are all being driven by QUnifiedTimer > > > > I'm curious how you found this! > > This was bothering me, so I was grepping around in the qt code for potential > culprits. QUnifiedTimer does seem to be a private API to qt. It could be > that the animations that never have this issue are driven by something else. > But at least in the case of system settings, it does _something_ that ends > up fixing this (maybe in kirigami?). It bothered me too, especially how intermittent the behavior seemed to be. This does cover the behavior described in BUG 455585 that we'd been tracking for some time. Great find, for real. This may indeed be an upstream QT bug that needs to be filed and looked at officially, they may have pointers on how to better handle it on the KDE side as well. (In reply to Orlando Rodriguez from comment #18) > It's great having a possible solution for this issue!!! Thanks!!!. Just a > quick question, is there any guide about how to patch qtbase and reinstall > it, so I can also test this? I have been googling a little bit and I found > the repo and the file for qt, but I still don't know how to replace qtbase > so this fix could work. Any information would be really appreciate it. (I > am using Fedora KDE 41 right now) The quickest way to test a one-line fix like this is to build a patched package for your distro, and install it over the system version. Most offer tools and helpers for this (PKGBUILD for Arch, fedpkg for Fedora, etc). Generally the package manager will overwrite the patched version on the next repo update. Even cooler is setting up an isolated container to do the build, so you don't have to install all the build dependencies on your main system :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #18 from Orlando Rodriguez --- It's great having a possible solution for this issue!!! Thanks!!!. Just a quick question, is there any guide about how to patch qtbase and reinstall it, so I can also test this? I have been googling a little bit and I found the repo and the file for qt, but I still don't know how to replace qtbase so this fix could work. Any information would be really appreciate it. (I am using Fedora KDE 41 right now) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #17 from n.parka...@gmail.com --- (In reply to Blazer Silving from comment #16) > > It looks like these animations are all being driven by QUnifiedTimer > > I'm curious how you found this! This was bothering me, so I was grepping around in the qt code for potential culprits. QUnifiedTimer does seem to be a private API to qt. It could be that the animations that never have this issue are driven by something else. But at least in the case of system settings, it does _something_ that ends up fixing this (maybe in kirigami?). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #16 from Blazer Silving --- > I assume this is upstream with qt. Does anyone know who I have to contact in > order to upstream this? A case can be opened at https://bugreports.qt.io/projects/QTBUG/issues, but.. This is still technically an issue with Kwin or whichever component is responsible for setting the timing interval properly. Changing the default lib value works (and it works beautifully), but it's still just a hack to prove this works. The value likely will need to be calculated dynamically based on monitor hz. > It looks like these animations are all being driven by QUnifiedTimer I'm curious how you found this! I've been scouring the plasma codebase and can't find anywhere that QUnifiedTimer::setTimingInterval() is referenced, or even portions of it. I checked user-installed plasmoids and other locations as well. If it can be properly set and retained globally as Kwin starts, it would have the same effect as changing the default upstream. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #15 from Paul --- Tried the patch on my system, X11 and Wayland both butter smooth now. (I used 4 ms to have a high enough refresh rate for a 240 Hz monitor). Arch Linux KDE Plasma: 6.2.4 KDE Frameworks: 6.8.0 Qt: 6.8.1 Kernel: 6.12.1-arch1-1 AMD Radeon RX 6950 XT -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #14 from dominickator122...@gmail.com --- WOW! This completely solves everything!!! I'm still kind of new to the whole Linux bug submitting experience, and I assume this is upstream with qt. Does anyone know who I have to contact in order to upstream this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 fililip changed: What|Removed |Added CC||t...@nitrosubs.live --- Comment #13 from fililip --- This has been bothering me for a while, thanks for the find! With the patch it's much, much better now. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Blazer Silving changed: What|Removed |Added CC||kdebugs@paul.network --- Comment #12 from Blazer Silving --- *** Bug 493208 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Blazer Silving changed: What|Removed |Added CC||breakingsp...@gmail.com --- Comment #11 from Blazer Silving --- At first glance, this works. Boy howdy! May also resolve BUG 455585, BUG 493208 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 n.parka...@gmail.com changed: What|Removed |Added CC||n.parka...@gmail.com --- Comment #9 from n.parka...@gmail.com --- It looks like these animations are all being driven by QUnifiedTimer, which uses a shared global tick, and the tick interval just defaults to 16ms. And if some component ends up calling QUnifiedTimer::setTimingInterval(), it would affect other animations since it's shared. It might explain why it fixes itself sometimes. If I apply the attached patch to qt6-base to change to default tick interval to 6ms, all the animations look smooth on my 144hz display (overview effect, system settings scrolling, the smooth scrolling in okular). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #10 from n.parka...@gmail.com --- Created attachment 176255 --> https://bugs.kde.org/attachment.cgi?id=176255&action=edit hack to increase qt6 animation tick -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #8 from copil...@gmail.com --- (In reply to copilexp from comment #7) > I get strange behavior on X11, It is "low refresh rate" when I log in, but > it somehow fixes itself after like two minutes, and then it is silky smooth. > However, the same cannot be said for Wayland. Nope, seems to be triggered by something. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 copil...@gmail.com changed: What|Removed |Added CC||copil...@gmail.com --- Comment #7 from copil...@gmail.com --- I get strange behavior on X11, It is "low refresh rate" when I log in, but it somehow fixes itself after like two minutes, and then it is silky smooth. However, the same cannot be said for Wayland. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Thomas Duckworth changed: What|Removed |Added CC||tduck973...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 justas changed: What|Removed |Added CC||jjom...@gmail.com --- Comment #6 from justas --- Still hasn't been fixed as of KDE Plasma 6.2.2. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 nethshanpe...@gmail.com changed: What|Removed |Added CC||nethshanpe...@gmail.com --- Comment #5 from nethshanpe...@gmail.com --- Can confirm that the issue persists in Plasma 6.2. As a laptop user this feels more noticeable especially when the using touchpad gestures to scroll through the desktops in overview mode. Operating System: Aurora 40 KDE Plasma Version: 6.2.1 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 Kernel Version: 6.11.3-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 22 × Intel® Core™ Ultra 7 155H Memory: 15.0 GiB of RAM Graphics Processor: Mesa Intel® Arc Manufacturer: HP Product Name: HP Spectre x360 2-in-1 Laptop 14-eu0xxx -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 username changed: What|Removed |Added CC||linx.system@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Vlad Zahorodnii changed: What|Removed |Added Component|wayland-generic |performance -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 --- Comment #4 from goingtosleep --- I encountered the same issue on wayland, with 165hz monitor, AMD RX 6600 XT, Plasma 6.1.5 on kernel 6.10.10. On X11 the animation is smooth, but every startup, I have to unsnap and snap a window to make it smooth, otherwise it's stutter. Basically like others mentioned. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 goingtosleep changed: What|Removed |Added CC||goingtosleep...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 reports_go_brrr changed: What|Removed |Added CC||gooda...@starmail.net Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Orlando Rodriguez changed: What|Removed |Added CC||sort...@gmail.com --- Comment #3 from Orlando Rodriguez --- (In reply to DT from comment #1) > I've encountered the same behavior on my 240hz display. The overview and > window snapping animations are the most noticeable, and appear (mostly) > correct on the X11 session. Peculiarly, the overview animation on the X11 > session renders at a lower framerate *until* a window is snapped to an edge, > following which it will begin rendering at the correct framerate. I found a > user on Reddit: > https://old.reddit.com/r/kde/comments/1c1lkiw/ > strange_lag_symptoms_with_the_overview_effect/ who reported similar issues > (along with the quirk in the X11 session I described). > > > Additionally, when scrolling in system settings the scrolling on the > > sidebar suddenly becomes a higher refresh rate when the "Colors and Themes" > > option is clicked. > I was able to reproduce this as well. Same here. I've had this problem with the overview effects and desktop grid since 5.XX. For X11 I created a post-login script to Alt-tab automatically as fast as possible (this brings the same effect than a windows snapped) and the animations were amazing again, however, that workaround has never worked on Wayland. It would be great if some day this issue could be solved, it looks difficult and probably the priority is low due to the effects are pretty functional as they are, but for me I have been searching for a solution, even I was thinking on thinkering the effects by myself, but in KDE6 they are not in the effects folders anymore. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485927] Animations in KDE Plasma 6 seem to be capped at 60hz
https://bugs.kde.org/show_bug.cgi?id=485927 Nate Graham changed: What|Removed |Added Component|"Manage Desktop and Panels" |wayland-generic |window | Product|plasmashell |kwin Assignee|plasma-b...@kde.org |kwin-bugs-n...@kde.org Target Milestone|1.0 |--- CC||n...@kde.org, ||xaver.h...@gmail.com Summary|Animations in KDE Plasma|Animations in KDE Plasma 6 |6.0.4 seem to be capped at |seem to be capped at 60hz |60hz| -- You are receiving this mail because: You are watching all bug changes.
