Games feel jittery even running at around 100 FPS about labwc

[Faugus]

@jp7677 I applied the patch as you suggested and it didn't change anything.

[Faugus]

@Consolatis it worked!
When I toggle it, the game becomes smooth.
But is there a way to enable it by default? System-wide, I mean.
Because I need to toggle it everytime I run a game and when I do it breaks the gamepad compatibility with the game.

[Consolatis]

Depending on the game WLR_NO_HARDWARE_CURSORS may prevent direct scanout from happen. Unless you have issue with the cursor without it I'd recommend removing the env var.

You could also try to give labwc a higher priority via nice (but need to ensure that the game then in turn starts at the default value).

[Faugus]

I set WLR_NO_HARDWARE_CURSORS because in some games (like Uncharted) the mouse cursor was stuttering with VRR ON.
I just tried to remove it and nothing changed.

I tried to set -20 priority to labwc and nothing changed aswell.

[Consolatis]

Just so that we are on the same page:

• VRR on, no recording, smooth game
• VRR off, no recording, smooth ?
• VRR on, recording, gameplay smooth, recording jittery ?
• VRR off, recording, gameplay smooth, recording jittery ?

[Faugus]

• VRR on, no recording, smooth game
• VRR off, no recording, JITTERY game
• VRR on, recording, gameplay smooth, RECORDING JITTERY
• VRR off, recording, GAMEPLAY JITTERY, RECORDING JITTERY

[Faugus]

I forgot to mention that on Last Epoch, the MangoHud's frametime graph is a straight line and running at around 100 FPS and feels jittery.

[Consolatis]

Alright, so:

• VRR on smooth gameplay and VRR off jittery gameplay.
• the recording is always jittery

Do you have a chance to test the same with sway 1.9?
They are now using the same rendering backend as we do so it might shed a light on the area where we can proceed to debug.

Completely random thought:
Does the same happen when using the vulkan renderer? (WLR_RENDERER=vulkan in ~/.config/labwc/environment)

[Faugus]

Do you have a chance to test the same with sway 1.9?

I could, but not today, unfortunately.

Does the same happen when using the vulkan renderer? (WLR_RENDERER=vulkan in ~/.config/labwc/environment)

I tried this before and it didn't change anything.

I just recorded a video to show you the jittery and looks like the recording is better now.
I think removing the WLR_NO_HARDWARE_CURSORS did the trick.

I'll do more tests and report back.

[jp7677]

I don’t know how trustworthy this is and if this is even related, but according to https://www.reddit.com/r/labwc/comments/1amhc4v/comment/kpmrk6n you could try to apply #1278 and may be (probably not) something changes.

[Faugus]

I've been doing some tests and I discovered that the mesa-git driver was affecting the framepace, so I installed the regular mesa driver.

With that out of the way, things got wierder:
Playing on KDE feels a lot smoother than on Labwc, but the recording on Labwc is smoother than on KDE.

Here's a video showing the comparison:
https://youtu.be/Z9H9afcptEE

[Consolatis]

This is not exactly an area of expertise of mine, so just some more random thoughts.

AFAIR the frame rate of the recording is dictated by the recording application. On wlroots based compositors there is also the choice between using shared system memory buffers (SHM) or GPU buffer handles (dmabuf). I don't know if there are recording applications out there that make use of that.

What are you using for the recordings, OBS via screenshare portal and pipewire? If yes you could try wf-recorder for testing as well (but that only works on wlroots based compositors). OBS might also have some wlr-screencopy-unstable-v1 protocol plugin.

Increasing the niceness of the recording application might also help.

[Faugus]

@Consolatis I'm using https://git.dec05eba.com/gpu-screen-recorder/about/ which only uses GPU.

But as I said, recording is better now, probably WLR_NO_HARDWARE_CURSORS was the problem.
Check the video https://youtu.be/Z9H9afcptEE.

The gameplay (without recording and VRR) is jittery compared to KDE. 100 FPS feels like 30 FPS, while on KDE is smooth.

[Consolatis]

@Consolatis I'm using https://git.dec05eba.com/gpu-screen-recorder/about/ which only uses GPU.

This seems to grab the frames directly from the DRM plane and thus skips the whole compositor layer. Very interesting. Thanks for posting that link.

As for why its jittery during normal gameplay (without VRR) I am not sure. You could potentially try the ToggleTearing action (along with https://labwc.github.io/labwc-config.5.html#entry_core_allowtearing).

[Consolatis]

As far as I remember the application can request the activation of tearing. So that is something that could potentially be done via wine but I don't follow the topic so don't know what is planned there.

For adaptiveSync we do have a fullscreen option so it gets enabled automatically when an application is in fullscreen.
Maybe we could add something similar for allowTearing.

In the meantime you could potentially use a windowRule, e.g. something like this

<windowRules>
  <windowRule title="some game title as shown in A-Tab">
      <action name="ToggleTearing" />
  </windowRule>
</windowRules>

Edit:
Potentially you could even use something like identifier="*" for the window rule and thus set it for all applications. I have absolutely no clue how that effects usual desktop applications though.

[Faugus]

  <windowRules>
    <windowRule identifier="*">
      <action name="ToggleTearing" />
    </windowRule>
  </windowRules>

That didn't work. I still need to toggle it manually.

[Faugus]

Maybe we could add something similar for allowTearing.

I think that would be the best option @Consolatis.

[Consolatis]

Maybe we could add something similar for allowTearing.

I think that would be the best option @Consolatis.

Thoughts @ahesford @Ph42oN ?

[Faugus]

KDE has this option enabled by default. That's why gaming without VRR is smoother on KDE.

[ahesford]

A fullscreen option to allowTearing was part of the original PR. We could add that option back by modifying get_tearing_preference in output.c to check for a fullscreen option and, if that's set, see if the active view is fullscreen; if so, it can return true without checking server->active_view->tearing_hint.

[Consolatis]

A fullscreen option to allowTearing was part of the original PR. We could add that option back by modifying get_tearing_preference in output.c to check for a fullscreen option and, if that's set, see if the active view is fullscreen; if so, it can return true without checking server->active_view->tearing_hint.

Thanks!
Added #1568 based on your suggestion.

@Faugus testing the PR would be much appreciated.

[Faugus]

@Consolatis Do I need to enable something in the rc.xml file?

I still have <allowTearing>yes</allowTearing>

[Consolatis]

@Consolatis Do I need to enable something in the rc.xml file?

I still have <allowTearing>yes</allowTearing>

Yes, it should be set to fullscreen.

[Faugus]

@Consolatis it's working!
The only problem is if I'm running on fullscreen and I try to change to borderless window, the game crashes.

[Consolatis]

@Consolatis it's working!

Sweet, thanks for testing.

The only problem is if I'm running on fullscreen and I try to change to borderless window, the game crashes.

Does the same happen when you use yes and ToggleTearing? And does it happen when you do not use tearing at all (e.g. a setting of no)?

[Faugus]

@Consolatis I tried with several games.
Looks like this window problem only happens with the Wine Wayland Driver.
With Proton and regular Wine everything works fine.
Since the Wine Wayland Driver is still in development, there's no need to worry about it now.

[Consolatis]

Well, the proper solution here would actually be for the wine wayland driver to set the tearing hint itself. But having a more generic option available on the compositor level still sounds like a good idea to me. We'll likely merge #1568 in a few days, after the release.

[Faugus]

Thank you so much!