Bug 446637

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 ***