Every 1/2 second or so during Steam (Proton) games, a dip in framerate

[juanejot]

This is a weird one, and my searches of similar issues reveals nothing that is both recent & similar: Under GNOME 46, the latest build (as of 4/8) seems to do this weird little blip to the frametime about every half second or so. Overall, this affects performance in a Horizon Zero Dawn benchmark by 2.5% or so. Not hugely significant, except that stutters are visible & the behavior is repeatable and consistent.
I wouldn't tie it to Dash-to-Dock at all, except that I've eliminated everything else (tried removing & replacing other extensions, scrutinizing & reverting recent package upgrades, etc.); turning off Dash-to-Dock makes the behavior go away* (as does removing it), and make -C install dash-to-dock install-ing it again (even after a git pull inside the dash-to-dock directory) & turning it on, brings the behavior back. I don't believe I noticed this before the most recent 4/8 commits (was not doing it, to my memory, after the 4/1 commits).
32GB 3600MT/s DDR4, 9700K, RX6600XT. Arch Linux (so, latest unless I've reverted anything, which I have not currently… the only exception being gamemode 1.7, because gamemode 1.8.1--any build--doesn't work.). Steam, mangohud, gamemode, all system packages (not flatpak).
That may already have been too much superfluous configuration info, but feel free to let me know of any other info you may need to explore & hopefully diagnose what's going on. Thanks for any time you can spend on this!
*And performance go back up to the expected range.

[vanvugt]

If we're talking about the unreleased master branch here, try changing the value of:

docking.js:const STARTUP_ANIMATION_TIME = 500;

or

prefs.js:const SCALE_UPDATE_TIMEOUT = 500;

to something like 2000. Does that then change the frequency of the blip?

[juanejot]

Thanks for your reply! I've only had time to try changing the value in docking.js (not prefs.js) so far, but before I saw your suggestion of 2000, I tried 1000. That improved the benchmark score to within 1% of previous/without Dash-to-Dock, and changing it to 2000 made it slightly worse, but still in the 1~1.5% range. Anecdotally, the blips seemed spaced at the same interval they had been before, and with the value set to 2000, there were as many... not blips, but 1/4ish second-long up/down dithers, I suppose you could call them (?) as with the original value of 500.

Also anecdotally and as expected given the file I edited, startup of Dash-to-Dock took longer, with the longer values (I assume they're for milliseconds?).

Also also anecdotally, I see from the source code for v89 from October (last stable release), than at least within docking.js, this STARTUP_ANIMATION_TIME value is not set, but referred to as a variable. Maybe it's set in another doc; I haven't checked.

Let me know if you suggest another value, or that I try it another time around with prefs.js instead. Not possible now, but I could try tomorrow.

Thanks again!

[vanvugt]

If it's "1/4ish second-long" then the value we're searching for is 250. I will try to do some measurements myself. Thanks.

[vanvugt]

I have not been able to reproduce this bug but I did rediscover an upstream bug affecting Xorg sessions.

• Are you using Wayland or X11?
• Are you able to try older commits and identify when the regression occurred for you?
• Does the bug only occur in fullscreen?
• Is your dock set to autohide?

[juanejot]

• I’m using Wayland, though Steam games—not the Steam client itself—still run(s*) in xwayland. Full Wayland support for games is apparently waiting for that feature of Wine 9.0 to be turned on in Proton 9.1 or so (?; timeline unknown).
• I tried to use what may be an older syntax git pull origin <hash of previous commit> but it kept reporting “up to date” & I didn’t see any code changes, so maybe I need a newer syntax or a better place than just the changes list, to pull my hash from?
• I run that particular game only in fullscreen, as a borderless window seems to insist on squishing FHD by drawing an unfilled panel at the top.
• It is set to intelligent autohide, I believe.

*UPDATE: xprop tells me the client's running in xwayland too, apparently.

[juanejot]

UPDATE: Finally taught myself the much more useful git checkout <hash> and can confirm that the last 4/2 commit does not show this behavior. Changing docking.js:const STARTUP_ANIMATION_TIME = 500; and prefs.js:const SCALE_UPDATE_TIMEOUT = 500; values within the current commit does make the performance fluctuate (never up to 100%), but reverting to the last 4/2 commit restores it (to within .01% or so of not even having Dash-to-Dock installed at all), even with these values set to their default 500.

Further can confirm that this effect and its current solution of rolling back to the latest 4/2 commit is not confined to my daily-driver vanilla (archinstall) Arch installation. Both a performance hit from the latest commit & an apparent restoration of performance from the 4/2 commit happen on an external CachyOS installation (so, Arch with v3 optimizations & some other specific choices) on the same hardware. I have not tried it on a Debian/Ubuntu- or Fedora-based (or -derived) installation.

[vanvugt]

Thanks, yes I was talking about using git checkout <hash>. Please tell us which hash values do and don't have the bug.

Also the "squishing FHD by drawing an unfilled panel at the top" in GNOME 46 is https://gitlab.gnome.org/GNOME/mutter/-/issues/3425

[juanejot]

I’ll edit the below once I can have a bit more time in front of the system. For now, the 4/2 commit with (short) hash 44a4726 works (eg. doesn’t cut into performance), and the latest pull (so I assume the same as 5d417c0) shows the performance hit. I have not yet but would be happy to test the intervening commits (1322cf7, d6c0b6b, etc.).

One question which further reveals my layman’s lack of git process knowledge (sorry): If a commit shows a ❌ or nothing, should I bother testing those, or only ✅-ed commits?

Watch this See my next comment for my updates on the intervening commits, if your answer to my question just above deems them salient.

And thanks for the tip on Mutter issue #3425; I’ll check it out!

[juanejot]

OK, commits vs performance behavior in Horizon Zero Dawn (Steam w/Proton & gamemode, mangohud) benchmarks:
👍 = "good" (within 0.01% of without Dash-to-Dock installed, with no regularly seen "blips" or less regularly seen "dithers.")
👎 = "bad" performance (~2% worse performance hit without above parameters in .js files changed, as little as ~1% worse performance with the range of changes mentioned above; note that I've only played with changing those parameters for commits 44a4726 and 5d417c0, and for this round of tests, left them at their default values of 500.)

Performance	Commit
👍	44a4726
👍	1322cf7
👎	d6c0b6b
👎	cfb78f5
👎	fe5dcc0
👎	5d417c0

So it appears that something about the new enable/disable code for unredirect of intellihide in commit d6c0b6b is affecting performance in my use case. I'm currently rolled back to commit 1322cf7, and it's working fine for my current needs, though of course I'm excited to see where Dash-to-Dock goes. There are many similar Gnome extensions; none of them really look as good or configure as well!

Thanks for all the work you do, and the chance to participate!

[vanvugt]

Nice work, thanks!

CC @taoky there seems to be a performance regression in d6c0b6b

[taoky]

Oh... It should have let the unredirection enabled when the dock is not showing (playing fullscreen games, etc). I would try if I could reproduce this issue today.

[taoky]

Oh... It should have let the unredirection enabled when the dock is not showing (playing fullscreen games, etc). I would try if I could reproduce this issue today.

I could confirm that the unredirection is disabled for multiple times when showing/hiding overview, as I didn't notice this when writing code.

I have worked out a fix: taoky@73afb79. @juanejot would you like to try if this works (If so I would submit a PR for further review)? Also enabling "RENDER" flag in looking glass (Alt+F2 => lg) could produce some useful information to journal, and could help see if unredirect is inhibited or not when running fullscreen apps.

[juanejot]

Thank you for the hard work, @vanvugt & @taoky!
The good news: 73afb79* appears to work, with no (quantifiable or stutter-noticed) degradation in performance.
The bad news: I was not able to figure out how to enable the "RENDER" flag; more on that below.
*Because it was on your separate repo (wise until live), I couldn't just run git checkout <that commit>. Instead, I checked out 5d417c0, and then copy/pasted the raw code from the only changed file, docking.js, on your repo's commit of 73afb79. That worked!
I'd be happy to learn how to set the "RENDER" flag if that would help, though I'm unsure whether the game may have something else mapped to Alt+F2; could start it before running the game & you'd get performance data on how other Gnome components/the Steam client are performing.

[emansom]

@vanvugt @3v1n0 What was the rationale for dash-to-dock to touch internal unredirect in the first place?

If it's performance related, shouldn't mutter MR 1441 mitigate that?

To me it seems to make more sense to keep extensions really simple, and cutting this out.

Then fix performance and rendering bugs upstream instead.

[taoky]

I'd be happy to learn how to set the "RENDER" flag if that would help, though I'm unsure whether the game may have something else mapped to Alt+F2; could start it before running the game & you'd get performance data on how other Gnome components/the Steam client are performing.

It's in "Flags" => "MetaDebugTopic". After this mutter (gnome-shell) would output more log that could be get by journalctl -f /usr/bin/gnome-shell. If unredirection is disabled (inhibited), it would print things like RENDER: No frame sync candidate: unredirect inhibited.

[taoky]

@vanvugt @3v1n0 What was the rationale for dash-to-dock to touch internal unredirect in the first place?

If it's performance related, shouldn't mutter MR 1441 mitigate that?

It's not related to triple/double buffering. The glitch I tried fixing is #1381, which could be triggered under Wayland session with maximized apps (such as Firefox with hardware acceleration on) on displays with no top bar (in a multi-screen setup, or when users install some other extension to hide the top bar).

To me it seems to make more sense to keep extensions really simple, and cutting this out.

Then fix performance and rendering bugs upstream instead.

In gnome-shell's code, the unredirect is disabled when the activated widgets (like the notification list, the system menu, or popups from the input method) could overlap with the window. But for extensions' own widgets, unfortunately this is not done automatically (though in gnome-shell, this is also done by explicitly calling Meta.enable_unredirect_for_display and Meta.disable_unredirect_for_display)...

Currently the unredirect APIs control a counter inside mutter -- this means if Meta.disable_unredirect_for_display(global.display) is called for N times, Meta.enable_unredirect_for_display(global.display) shall be called for N times to revert the change. This also means that extensions could maintain its own state: disable unredirect once when it needs to show a widget that could overlap with (maximized) windows, and enable unredirect once after it hides.

I agree that the unredirect APIs are not quite easy to use, and I don't know if https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3043 could alleviate this issue.