Bug 341669 - Make MaxFPS configurable
Summary: Make MaxFPS configurable
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kwin
Classification: Plasma
Component: scene-opengl (show other bugs)
Version: 4.11.12
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: 5
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-08 19:47 UTC by Guillaume Racicot
Modified: 2022-01-19 19:20 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Racicot 2014-12-08 19:47:03 UTC
I tested Kwin abilities to render on a 144Hz monitor. Everything is fine until I turned the vsync on. I tried both with the three vsync options. With my monitor at 144Hz and Vsync, I do not get tearing, but the framerate seems lower than it should. Then when I turn the vsync back off, The framerate drops at about 60Hz (frame capping?). When I put my monitor at 120Hz and turn the Vsync on, eveyrhing seems fine and no lag what so ever. I got an NVidia GTX 970 with the latest drivers.

Reproducible: Always

Steps to Reproduce:
1. Put your X server to 144Hz mode (with a 144Hz capable monitor)
2. Put the Vsync off and back on in the vsync mode you prefer
3. shake some window (the effect is more visible with wobbly window)

Actual Results:  
The framerate seems lower than it should.

Expected Results:  
The framerate sould be a steady 144.

Do not happend with at 120Hz.
When the vsync is turned back off, the framerate is locked at 60. It should be locked at least at the monitor native framerate.
Comment 1 Thomas Lübking 2014-12-08 19:58:17 UTC
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?
Comment 2 Guillaume Racicot 2014-12-08 20:07:14 UTC
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?)
Comment 3 Guillaume Racicot 2014-12-08 20:08:38 UTC
I changed the bug's title. Should this be okay?
Comment 4 Guillaume Racicot 2014-12-08 20:28:27 UTC
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.
Comment 5 Thomas Lübking 2014-12-08 20:42:37 UTC
(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.
Comment 6 Guillaume Racicot 2014-12-08 20:50:14 UTC
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.
Comment 7 Thomas Lübking 2014-12-08 23:05:29 UTC
(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?
Comment 8 Guillaume Racicot 2014-12-09 00:01:16 UTC
(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.
Comment 9 Allan 2016-10-17 21:17:28 UTC
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.)
Comment 10 Guillaume Racicot 2016-10-17 21:27:43 UTC
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?
Comment 11 Allan 2016-10-18 08:12:23 UTC
Yea, I did notice too, that setting "Tearing prevention" to "Automatic" - MaxFPS seems to be ignored.
Comment 12 Guillaume Racicot 2016-10-22 22:10:13 UTC
Since this bug is about making MaxFps setting available to users and not about vsync ignoring MaxFps, I'll report another bug for that.
Comment 13 Vlad Zahorodnii 2022-01-19 19:20:22 UTC
MaxFPS was dropped.