Closed sumeshir26 closed 2 years ago
time.clock seems like the best solution to me
We could try options 2 and 3, the only problem is that if you are compiling with option 3, you need C# tools. I guess that's a pain. I'd prefer option 2 since that'd make compiling easier.
A question - does time.clock
consume huge chunks of RAM?
No Idea, the last time I messed with that was over a year ago, I at that time more than making semi-polished apps, I just wanted to learn
But does it? Why not integrate it before Republic Day?
I'll try
Started work on this!
Closing as Resolved
The Problem
After running a test side-by-side of the Windows 11 clock app and TimerX of 30 Minutes, TimerX lags 22 seconds behind.
Cause
TimerX does not use a actual timer, it just waits for a second and then takes a few milliseconds to process it(Update
time_display
,seconds_left
, etc .). Those milliseconds add up and cause a lag.Possible Solutions
multiprocessing
instead of threads to provide higher prioritytime.clock
to actually count real time. A benefit of this is that TimerX will then count in milliseconds which will lead to almost-instant pausingC#
function for thetimer_thread
@not-nef and @im-coder-lg what are your thoughts?