Open HauptlingHD opened 3 days ago
Are you talking about the GUI or the CLI?
I'm guessing the GUI since I already do rounding on the CLI. What I could do is to round it off to two digits after the decimal point like this:
As for the frequency of the update, currently it's 10 times per second. I guess we can make that four times or twice a second or something.
Yes, I was talking about the GUI. Good to know that it doesn't update the counters in real time, but 10 times per second almost looks like real time to me. At least in terms of readability. The "jumpy" and "glitchy" behavior (for leg of a better word) doesn't make it easy to read the counters.
https://github.com/user-attachments/assets/3529bb3b-582f-47f2-9376-faa04c38ccb6
See how the FPS jumps back and forth and the Time Remaining doesn't give me a clear value but changes by multiple seconds all the time?
My personal preference would be one rounded digit after the decimal point for FPS and one update per second for all counters. But again, I think the most user-friendly solution would be to give the user a setting where they can choose "FPS digits after decimal point" and "Status update/s" for themselves. One other solution I thought about was letting the user choose to either see the current FPS (as it is right now) or give them the option to see the average FPS of the last 5 or 10 seconds. This would also "smooth out" the counters a bit.
I don't want to add too many settings as it may overwhelm the users. I think it's fair to reduce the update speed to something more reasonable. I'd say something like twice per second would work fine.
I'll also apply the adjustment for the rounding so it always shows two or three digits after the decimal point.
The FPS math will be enhanced later. Right now it's just frames_processed / time_elapsed
.
Currently (Version 6.1.1) the FPS counter, "Time Elapsed" and "Time Remaining" update in real time. This makes it really hard to read what is getting displayed, especially when your remaining time is large enough for a small fluctuation in FPS to let the remaining time jump up and down 10 or 20 Seconds.
Real time updates of such counters also leads to unnecessary CPU time spent on something that the user won't be able to read anyway. This also means unnecessary power spending. (Of course, both of these things are pretty negligible but real nonetheless)
One last thing real time updates for the counters are bad for is a display with a variable refresh rate. If Video2x runs, e.g. on a laptop display with a variable refresh rate of 30–120 Hz, the display would be forced to update at 120 Hz as long as the Video2x GUI is visible on screen, again wasting power.
My suggestion:
Either update the counters much slower or give the user a setting to choose how fast they want the counters to be updated. That way the user can choose how they want the GUI to behave, which allows them to save some power.
(Also, the FPS counter is very "jumpy" since it can go from "1.5" to "1.49999" every other frame. Maybe show fewer decimal places and/or make all zeros after the decimal point always show up, so it would say "1.50000" instead of "1.5".)