With a screen at 60hz this works as expected taking 5 seconds, sleep is just there for a timer kdialog --passivepopup 'hello world' 5 --title 'hi' --icon documentinfo && sleep 5 now if you set the fresh rate to 120hz and repeat like this (do not feel like doing the math for 144hz) kdialog --passivepopup 'hello world' 5 --title 'hi' --icon documentinfo && sleep 2.5 this notification should expire in 5 seconds however it will expire in a measly 2.5 seconds notification expiration should be linked to time not a monitors refresh rate Operating System: Kubuntu 22.04 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.16.0-051600rc4-generic (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: Radeon RX 580 Series
Downstream report: https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/1952564
Sounds a lot like https://bugs.kde.org/show_bug.cgi?id=419421
Yeah seems like the same issue, but there's no NVIDIA GPU involved here... If you run `kcmshell5 qtquicksettings` and change the render loop to "Basic", does the problem go away?
Render loop has no effect
probably worth noting that this is reproducible on wayland
I can also reproduce this as described using this hardware by setting the refresh rate to 50hz then it takes longer than expected Operating System: Kubuntu 22.04 (Daily Live: Dec 1 2021) KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-19-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i3-2100 CPU @ 3.10GHz Memory: 3.7 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 2000 Now this is interesting, if i log out of X11 @ 50hz then log into wayland there is no issues at 50hz, bus as soon as a set it to 60 hz it takes expires too soon (tested on above hardware)
Even if you do not have a high refresh rate monitor if you can a 4k TV you can probably get a 60hz and a 30hz option maybe you have a old CRT lying around you can try it may have a 60/75hz support
Fascinating. Unlike Bug 419421, I wonder if this is purely a Qt issue.
My guess is someone knew what they were doing when they tied it to the refresh rate and made it handle 50/60hz back in the day when 50hz was EU and 60Hz was USA, the code to do this assumes you can't apply the new refresh rate without logging in to the session, this is based on there 144hz being a problem even after logging in after changing the fresh rate and it just goes assumes 60hs cause it is not 50 in a if else check maybe the code in use is not that old? The real question is if they knew what they were doing why did they not just use math to calc the fps to get the time right
You may be thinking of the electric mains frequency; this bug is about monitor refresh rate. Both are measured in hz, but only one is relevant here. :)
Maybe that was just CRT TVs? i know about it cause of classic consoles (like the NES) and how the different region's games run slightly different, knowing this is useful for in game timer speed run records where less than 1 frame matters cause it will round different on one version than the other
Log out of X11 Login into wayland change refresh rate will not sync up logout of wayland login to wayland now in sync changing it will usually keep in in sync (usually) at this point i got it to glich to somewhere between synced with 144 and 120 hz in wayland (i have no refresh rate between these) maybe it is not syning with 120/140hz at all and is just in accurate? looks like i am getting 87% accuracy at 144hz *** this is wayland not x11 144Hz: setting to 10 sec gives 8.7 real time 120Hz: setting to 10 sec gives 11.5 real time 100Hz: setting to 10 sec gives 10 sec real time 60Hz: setting to 10 sec gives 10 sec real time 50hz: setting to 10 sec gives 10 sec real time even after a reboot this list seems accurate any idea how i can set the refresh rate on the login screen to see if that affects anything?
When using this GPU: Graphics Processor: Mesa DRI Intel® HD Graphics 2000 (Intel Sandy bridge) at 144hz setting to 10 seconds is 7.3 seconds * i found another display port cable so no more display -> div -> hdmi also worth noting it takes about 1 second after giving the command for the notification to appear on screen, probably worth remaining everyone that this is 8 year old integrated graphics
above comment was with wayland, when using x11 it is just as broken as w/ amd
On X11 i just figured out if a set the refresh rate in sddm it improves the situation ---------- $ cat /usr/share/sddm/scripts/Xsetup #!/bin/sh # Xsetup - run as root before the login dialog appears if [ -e /sbin/prime-offload ]; then echo running NVIDIA Prime setup /sbin/prime-offload /sbin/prime-offload fi xrandr -d :0 --output DisplayPort-1 --refresh 144 --mode 1920x1080 --set "TearFree" on --output DisplayPort-2 --primary --refresh 144 --mode 1920x1080 --right-of DisplayPort-1 --set "TearFree" on ---------- by doing this a 10 sec notification last 8.7 seconds instead of less than 5 seconds, i'd guess this will just make it behave the same ass wayland No idea if the --set "TearFree" on is needed, that is just the command i used in a script i made when i was messing with freesync on xubuntu 20.04
Does it also happen when you reduce the resolution?
you mean run low like 640x480? what scenario do you want tested from login to session (x11 or wayland)
If i set the login screen to 120hz and login to 144 hz a 5 sec dialog last about 3.7 seconds if login screen is set to 144hz and a login to 144 hz a 5 second prompt last about 4.3 sec * this is using x11 i am eyeballing these times, so it is not but so accurate, but what i can see if login screen and session are the same at 100hz and below the timer is correct, but 120 and 144 off a bit, but having login at 60hz and the session at 120hz gives 5 sec prompt as 2.5s the login screen refresh rate should not be affecting the prompt timer in the 1st place, but changing the refresh rate of the login screen to match a x11 session does fix or lessen the severity of the issue depending on the refresh rate
*** Bug 454289 has been marked as a duplicate of this bug. ***
*** Bug 451252 has been marked as a duplicate of this bug. ***
*** Bug 448666 has been marked as a duplicate of this bug. ***
Pretty sure this isn't a Plasma bug, but I don't know where it would be. KWin, Qt, or the graphics drivers, not sure. Moving to KWin for now since the people who look at bug reports there are very smart.
doubt it is graphics drivers, it affects nvidia (nouveau), amd, and intel maybe someone can test this on a raspberry pi?
This is a bug in Qt. The QML timer object uses an animation for timing, which means all the bugs related to animation timing in QtQuick apply to the QML timer. See for example https://bugreports.qt.io/browse/QTBUG-96774 , https://bugreports.qt.io/browse/QTBUG-60976 and https://bugreports.qt.io/browse/QTBUG-43296 . In general I consider the animation timing in QtQuick with the threaded render loop to be broken by design as it relies on blocking calls instead of measuring the elapsed time. One workaround might be to force the basic render loop, which should have more reliable timing.
Moreover, according to https://bugreports.qt.io/browse/QTBUG-59300?focusedCommentId=349519&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-349519 this behaviour is intentional.
Sounds like we can either plead our case there again, or else implement a local workaround. :/ It's been 5 years since that comment was posted though; maybe we can convince them that it's a real and growing problem now?
how can i force a basic render loop to see if that does anything, maybe i can test that at some point Really should take amd gpu out of the title, the only gpu i think this does not affect is nvidia w/ the proprietary driver (i know i tested everything else: Intel, NVIDIA (nouveau), and AMD)
Search for "Plasma Renderer" in KRunner or Kickoff > click on it > change "Render Loop" to "Basic. FWIW we have reports of this affecting NVIDIA users too; see Bug 419421.
(In reply to Nate Graham from comment #28) > Search for "Plasma Renderer" in KRunner or Kickoff > click on it > change > "Render Loop" to "Basic. > > FWIW we have reports of this affecting NVIDIA users too; see Bug 419421. Now that this issue is solved, is there a way i can test that version of qt on kubuntu 22.04 LTS, like a PPA? i have just been mitigating this issue by setting the refresh rate at the login screen
Apparently fixed in Qt 6.4; see Bug 419421. *** This bug has been marked as a duplicate of bug 419421 ***