https://bugs.kde.org/show_bug.cgi?id=369349
--- Comment #27 from alvinhoc...@gmail.com --- How is this suddenly a problem again? I briefly checked the code and I couldn't see any major changes since my fix last year. I also tried the latest nightly just now to check, and it seems to behave exactly the same as before. One thing though, is that the default value of `stabilizerDelayedPaintInterval` is set to 20, which results in a 50Hz update rate. On most systems however, the default refresh rate of the monitor output is set to 60Hz, which if the screen is redrawn 50 times in a second, does cause some minor stuttering. But that is nowhere near as bad as the 20Hz used before the fix. Sure, it isn't as good as in Krita 2.9, but in this case the stabilizer in Krita 2.9 had always been working incorrectly so it's not really comparable. In case you do want a better "redraw rate" (!) that matches the refresh rate of your monitor, do the maths 1000 / <monitor refresh rate>, round the result down to the nearest integer (full number without decimal point) and set the `stabilizerDelayedPaintInterval` config to that value. For example, if the refresh rate of your monitor is 60, the maths will be 1000 / 60 ~= 16, then you would add `stabilizerDelayedPaintInterval=16` (without quotes) to the config, or replace the existing config value of it. If the refresh rate is 75, then it would be 1000 / 75 = 13. Why I didn't use `stabilizerDelayedPaintInterval=16` as the default though, I don't really remember what I was thinking. So if anyone think it should be changed, feel free to discuss it with @Boud. Or if perhaps there are other ways to do it properly that I didn't think of, feel free to implement it. Someone may consider adding it to the manual. (!): Note that the redraw rate does not directly translate to resulting framerate, because v-sync and double buffering exist. -- You are receiving this mail because: You are watching all bug changes.
