Bug 341669

The framerate is capped at 60Hz
kwriteconfig --file kwinrc --group Compositing --key MaxFPS 144
kwin --replace &

please elaborate on "but the framerate seems lower than it should" - 60Hz as well?

Sorry for the misleading description.
The framerate is at about 73 or 75 when the Vsync is on with my monitor at 144Hz. It seems to miss one frame of two.

When my display is at 120, the FPS plugin goes to it's maximum: 100, even if the real framerate is at 120.  I suspect a bug from the show FPS plugin as the real framerate seems alright. (should I report a bug for that too?)

I changed the bug's title. Should this be okay?

oh that was quick. Changing the config seems to have fix everything. One million thanks.

Bug normal users may not see this bug report and may not run that command to change the config. Is there a way this could be automated? Like kwin taking that actual framerate instead of the config? This may be useful for users not knowing about this config.

(In reply to Guillaume Racicot from comment #2)
> The framerate is at about 73 or 75 when the Vsync is on with my monitor at
> 144Hz.
It's up-aligned from 60Hz (should be 72Hz)

You can forget about the FPS module in this regard, it actually impacts/pollutes repaint speed (unless buffer swapping blocks for sync) and afair is indeed capped at 100Hz, that's NOT related to the MaxFPS setting. (The FPS counter is pretty old)

> should I report a bug for that too?
You may, but personally, I'd rather drop the plugin and add some statistic code to the compositor (to be activated and queried eg. via dbus or QtScript) to prevent inherent pollution.

(In reply to Guillaume Racicot from comment #4)
> Like kwin taking that actual framerate instead of the config?
Actually, fps capping exists to
   a) catch buggy refresh rate information
   b) keep CPU load "resonable"
with 60Hz picked for obvious reasons.

We could expose it to the config GUI, though.

Exposing the config to GUI could be a fast solution. However, this add redundency of the config: You have to adjust the actual refresh rate and then the window manager refresh rate, that you obviously want to be the same. A not advanced user will find this confusing and may be mixing up the two framerate. It should be automated as the window managed *should* know the actual framerate. 

In the case of a buggy framerate information, then 60Hz should be picked.

Buggy framerate information should happen less in the wayland world.

The solution of exposing this config to the GUI seems fine for the moment as a workaround, but the ideal solution should be automatic framerate.

(In reply to Guillaume Racicot from comment #6)
> that you obviously want to be the same
Yes? Why?
If my screen can run @400Hz, why should I repaint the desktop at that speed?
Waste battery? Heat the room?

Did you really *see* that the framerate dropped < 100Hz or did you figure that using the FPS counter?

(In reply to Thomas Lübking from comment #7)
> (In reply to Guillaume Racicot from comment #6)
> > that you obviously want to be the same
> Yes? Why?
> If my screen can run @400Hz, why should I repaint the desktop at that speed?
> Waste battery? Heat the room?
> 
> Did you really *see* that the framerate dropped < 100Hz or did you figure
> that using the FPS counter?

I saw the framerate dropping, that's why I investigate on the problem and that's why we are here. Switching to 120Hz was a relief because it displayed every frames at 120 FPS. Switching to 144Hz with ~73 FPS was enough noticeable to be annoying, and may be noticed by other users.

If you pay for a 144Hz screen, maybe it's because you want your computer to display 144 frames per second. But considering power efficiency, framerate does not change a lot of things unless you have a graphic intensive app that redraw every frames. Kwin redraw only the part it needs to be redrawn, and we are talking about Kwin limiting the framerate, so it should not heat the room much more.

If you considering KDE running on battery, now the limiting the framerate below what the screen can display may extends the battery autonomy. But it's not applicable when the A/C is plugged-in with a fully charged battery. Could we add an option in the power settings to handle this? Maybe, but that's out of this bug report bound. The issue is about an unwanted limited framerate.

Arbitrarily capping the framerate to 60 was valid for a long time, because nearly every screens was made to run at this frequency, but high framerate screens are becoming more mainstream especially by enthusiast users, making this assumption invalid.

I'm glad I found this page-- since unredirect disappeared I've been searching for bug-free, tear-free and lag-free solution to a fullscreen game -on one of my monitors.

Apparently setting tear prevention to "Never" and (manually editing the conf) /turning MaxFPS up to 240 in KWin 5.8.1 -while leaving compositing on during the game solves all three for me.
As a side bonus - Opera scrolling is also tear-free, same for videos..

Oddities I have noticed maybe someone can explain..?
- Fans stay off, powermizer (nvidia) stays on lowest, temperature and kwin cpu usage is low/ change undetectable- even when moving windows about and scrolling in Opera.. (Not in game)
- FPS "effect" says 100fps (and kwin consumes 20% cpu on a single core while fps counter is running) - I guess it's just the highest it can measure.. For when actually setting maxfps to 100 - massive tearing appear.
- Zero fps loss in game, in fact there was a slight performance GAIN in the game!? I had expected to lose performance due to the massive blitting needed - instead performance in game went up about 2-5%.. I tried turning compositor on/off several times to recheck..

(Game engine is springrts and gpu is gtx970.)

In recent version of kwin_x11, I ended up disabling vsync. Even when setting up the max fps to 144, simply enabling tearing prevention caused heavy stuttering on my screen (you know, 144/60 is not an whole number). It did, however, prevent tearing.

With tearing prevention disabled, kwin seems to respect the max fps setting. That makes thing as smooth as my screen can handle, but I get tearing.

Anyone can confirm the issue here?

Yea, I did notice too, that setting "Tearing prevention" to "Automatic" - MaxFPS seems to be ignored.

Since this bug is about making MaxFps setting available to users and not about vsync ignoring MaxFps, I'll report another bug for that.

MaxFPS was dropped.