by dpJudas » Sat Feb 01, 2025 3:39 am
If it were up to me I'd remove the code. First of all the OS itself already boosts priority on foreground apps. Secondly, lowering the FPS to 30 (or whatever it is set to) already deprioritizes the app when its in the background. Third, we live in a multicore world today, so its not like it directly interrupts the running thread of the foreground app anyway. And last, the thread still has to run eventually, so whatever micro-stutter its meant to avoid is still going to occur, if that is what is trying to avoid.
I also once read an article, although I can't really find it anymore to link it here, that effectively argued that the entire concept of thread priority class is broken. The issue is basically that in a chaotic world where there's literally hundreds of threads doing all kinds of stuff, knowing what is important how long a "low priority" thread can be delayed without severe negative impact is impossible to predict. It is a bad 90's idea that should be left there.
PS. If a debugger is attached to a process that changes thread priorities and how threads are scheduled too, so that also shouldn't be the purpose of this code.
If it were up to me I'd remove the code. First of all the OS itself already boosts priority on foreground apps. Secondly, lowering the FPS to 30 (or whatever it is set to) already deprioritizes the app when its in the background. Third, we live in a multicore world today, so its not like it directly interrupts the running thread of the foreground app anyway. And last, the thread [i]still[/i] has to run eventually, so whatever micro-stutter its meant to avoid is still going to occur, if that is what is trying to avoid.
I also once read an article, although I can't really find it anymore to link it here, that effectively argued that the entire concept of thread priority class is broken. The issue is basically that in a chaotic world where there's literally hundreds of threads doing all kinds of stuff, knowing what is important how long a "low priority" thread can be delayed without severe negative impact is impossible to predict. It is a bad 90's idea that should be left there.
PS. If a debugger is attached to a process that changes thread priorities and how threads are scheduled too, so that also shouldn't be the purpose of this code.