| Summary: | KWin/Wayland capping framerate to 60 fps in XWayland in borderless fullscreen (Wine) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Shmerl <shtetldik> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | kde, leguen.yannick |
| Priority: | NOR | ||
| Version: | 5.14.3 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Shmerl
2018-12-05 20:09:35 UTC
What's the purpose of having a refresh rate higher than your monitor? (In reply to David Edmundson from comment #1) > What's the purpose of having a refresh rate higher than your monitor? Testing performance of graphics drivers for instance. KWin is synced to the frame rate of the screen. On the other hand KWin does not limit the frame rate of windows. They can render as many frames as they want. Just KWin won't render them. (In reply to Martin Flöser from comment #3) > KWin is synced to the frame rate of the screen. On the other hand KWin does > not limit the frame rate of windows. They can render as many frames as they > want. Just KWin won't render them. So if it doesn't limit it, why is framerate reported as unlimited in KWin/X (i.e. it can fluctuate and go above 60 fps), and capped at 60 fps in KWin/XWayland? I used dxvk internal HUD to display it and it shows the difference. May be then calculation of the (potential) framerate should be done differently somehow? I.e. physical framerate is always capped by the monitor refrerh rate either way. When various HUDs report framerate in X it's the potential one. But somehow this calculation produces different results now in X and XWayland with KWin. You have to ask the XWayland developrs why they cap the frame rate. As I wrote KWin does not limit applications, they can render at whatever frame rate they want. We honestly don't care at all. OK, I'll follow up with XWayland developers. Opened new XWayland bug: https://gitlab.freedesktop.org/wayland/wayland/issues/67 XWayland developers also suggest for the compositors to:
> Basically, the compositor must not reparent a "borderless fullscreen" X11 window to a larger X11 window (e.g. for drop shadows).
Sorry for confusion, I opened it for the wrong project (Wayland). It should have been for Xorg, so here is the correct one: https://gitlab.freedesktop.org/xorg/xserver/issues/20 We reparent all x windows and we won't change that. To give an update. This actually looks specific to Wine+dxvk (Vulkan) case and it doens't happen in Wine+wined3d (OpenGL). On Archlinux with Kwin 5.19.5, I also notice a difference between OpenGL (native games or wine + wineD3D) and Vulkan games (wine + dxvk in that case). I have a 144hz display. OpenGL games on Plasma-wayland are smooth, while Vulkan games are stuttering. However, when I start a Proton game with the "DXVK_HUD=fps" parameter, the FPS counter can go beyond 144 fps (it depends how well my GPU performs I guess), it doesn't seem to be capped to 144 fps even though the game is visibly stuttering. I'm not sure if my observations are related to this bug report or if I should open a new one. |