search

Zren / plasma-applet-eventcalendar

https://store.kde.org/p/998901/
469 stars 92 forks source link

Timer running too fast #129

Open beojan opened 4 years ago

beojan commented 4 years ago

The timer is running too fast, showing a second elapsed after approximately 0.5 s.

Zren commented 4 years ago

I've no idea how that could happen. There's only 1 Timer instance and it only triggers every 1000ms.

https://github.com/Zren/plasma-applet-eventcalendar/blob/master/package/contents/ui/TimerView.qml#L263

If anything, I'd expect the overhead of the timer would make it take longer (eg: 2h00m30s instead of a clean 2h).

sahsanu commented 4 years ago

Same issue here, timer for 30 seconds ends in 15 seconds, 1 minute in 30 seconds and so on.

Event Calendar v66 KDE Neon 5.18.5 QT 5.14.2

Zren commented 4 years ago

Does it happen all the time? Even after a reboot?

sahsanu commented 4 years ago

No, it doesn't happen all the time. Sometimes works fine and other times it is too fast (0.5 seconds instead of 1 second). I can reboot and it works fine after reboot or I reboot and it doesn't work fine, it is a bit erratic in my case. Really weird.

beojan commented 4 years ago

That's exactly what I see too.

Zren commented 4 years ago

The only thing I can think of besides a QML bug is:

If you pause the timer, does it still count down? Does it still go at double speed when you unpause it?

I could move the Timer {} to the widget's main.qml if this is the case. As the main Item/object is never unloaded. I ran into a similar issue when I had the event notifcation code inside the popup.

beojan commented 4 years ago

It goes at double speed from the moment I start the timer, so the popup is never closed. Of course when I go to test it, it works, making it pretty hard to debug.

I should add, I have eventcalendar in a Latte Dock. @sahsanu, what about you?

sahsanu commented 4 years ago

If you pause the timer, does it still count down?

No, it pauses correctly.

Does it still go at double speed when you unpause it?

Yes, if it started double speed no matters whether I pause/unpause, it continues at double speed.

I should add, I have eventcalendar in a Latte Dock. @sahsanu, what about you?

I've latte-dock installed but Event Calendar is on a normal panel, not a latte-dock panel.

JuBan1 commented 4 years ago

It happens to me too. Here's a video of it: https://streamable.com/49bpuw

Manjaro Linux, Plasma 5.18 (and several versions prior))

What's even weirder: sometimes it works fine. Occasionally I'd use the timer and it's too fast, then I'd use it a few hours later (without restarting anything) and it would work fine.

I'm thinking it might be related to the display refresh rate (or rather, VSync). I have a 144Hz monitor, which is ~2.5x more then 60Hz, and the calendar timer runs ~2.5x faster than it should. In addition there have been issues like that in the past. 1 2

But it's not as easy as just going back to 60Hz. That doesn't fix it- at least not immediately. So I might be on the wrong track. But even just fiddling around a bit right now as I collected information, somehow, the calendar timer once again started working properly.

Zren commented 3 years ago

So apparently this was a bug in Qt 5.4.x. Someone also mentioned on StackOverflow that it's tied to the refresh rate. I guess I will go with (timeStarted + duration) - timeNow = timeLeft rather than using a QML Timer tick every second...

... Or I could use the time datasource... like the clock uses... I've been an idiot for not using it all this time. I got caught up in trying to figure out what was wrong with QML Timers.

JuBan1 commented 3 years ago

Good to hear. I can help if you need someone to test a patch. I can consistently reproduce the behavior, unfortunately.

Zren commented 3 years ago

It should work now. It still uses QML Timer, and will likely redraw multiple times, but it now uses this logic:

def start():
    timeLeft = duration
    unpause()

def unpause():
    finished = now + timeLeft

def tick():
    timeLeft = finished - now

I still need to figure out a "timestamp that isn't affected by timezones" like how many seconds the plasmashell process has been running. Right now I think Daylight Savings Time or physically moving over timezones might break my timer logic. Perhaps I can force the QML Date to use UTC timezone instead of the default local timezone new Date() probably uses.

JuBan1 commented 3 years ago

(Ignore my last comment if you saw it. I did a ./reinstall but it work; so my previous comment was still about the buggy code.)

I tested it and it does work accurately now.

Zren commented 3 years ago

There's also a KDE Bug report that some of you might be able to reproduce.

EverardNisse commented 3 years ago

Can reproduce the KDE bug with 144+75 Hz displays / 144+60 Hz. They're on the right track, the workaround mentioned there seems to also work.