[Performance regression] doubled frametimes with flathub 0.8.2 -> 0.8.3 upgrade

[SjoerdV]

Describe the bug

Input lag (frametime graph amplitude spikes). having max 20ms with previous flathub commit, now it reads 38ms consistently. Reverting to flathub commit d914f05f203c2a0345489f26ee527a5bf8e44f2cd6a646296b8151dea2d6e190 fixes the issue.

System information

Please provide all relevant details.

• Linux distribution CachyOS
• Kernel version 7.0.1
• MangoHud version 0.8.3 commit 6562451c47106855771ed58f42061c341ab17f572bbd5a10146b2adf496b6b6d
• MangoHud config (attach or paste if non default)
• Launch options default with latest cachyos-proton under bottles
• Application or game any DX12/VKD3D engine game
• GPU model and driver RTX4060
• Display server Wayland

Expected behavior

minimum frametime latency

Actual behavior

nearly double the frametimes

Logs

Include log captured with MANGOHUD_LOG_LEVEL=debug set

Wrap logs in code blocks.

Screenshots

If applicable, add screenshots to help explain the problem.

Additional context

I am using lsfg-vk x3 framegen with locked vkd3d/dxvk 40fps frame cap on game. Mangohud reporting 120fps in all cases. No other config changed but the Mangohud flathub version upgrade. Fully repeatable. Reverting to 0.8.2 fixes the issue.

[17314642]

What commit are you talking about? I couldn't find it in mangohud repo or flatpak mangohud repo

[SjoerdV]

flatpak remote-info --log flathub org.freedesktop.Platform.VulkanLayer.MangoHud/x86_64/25.08

MangoHud - Vulkan/OpenGL overlay for monitoring FPS, temperatures, CPU/GPU load
and more

        ID: org.freedesktop.Platform.VulkanLayer.MangoHud
       Ref: runtime/org.freedesktop.Platform.VulkanLayer.MangoHud/x86_64/25.08
      Arch: x86_64
    Branch: 25.08
   Version: 0.8.3
   License: MIT
Collection: org.flathub.Stable
  Download: 11.2 MB
 Installed: 31.9 MB

    Commit: 6562451c47106855771ed58f42061c341ab17f572bbd5a10146b2adf496b6b6d
    Parent: d914f05f203c2a0345489f26ee527a5bf8e44f2cd6a646296b8151dea2d6e190
   Subject: Fix x-checker-data for nvidia-settings (82f2b1bb8ddd)
      Date: 2026-04-25 18:37:46 +0000
   History: 

    Commit: d914f05f203c2a0345489f26ee527a5bf8e44f2cd6a646296b8151dea2d6e190
   Subject: Remove unnecessary build option (7a14b1a21253)
      Date: 2025-12-02 18:39:44 +0000

    Commit: 92311e7612686da84305caf74e4f8d9848dbbe314559db438155cf38da738af3
   Subject: Update SDK to 25.08 (bed022f7c2ac)
      Date: 2025-09-05 15:43:20 +0000

[17314642]

For some reason you have different commit ids

https://github.com/flathub/org.freedesktop.Platform.VulkanLayer.MangoHud/commits/branch/25.08/

EDIT: I see correct commit ids in parentheses

[17314642]

Only thing changed in latest commit is adding patch version check, no code changes

Only thing I could suggest is compiling mangohud from source and checking if this issue persists

[SjoerdV]

I thought flathub updates were cumulative (just selecting a specific commit to publish on flathub, is just flattening the source up to that point in time and NOT cherrypicking that specific commit? but I could be wrong...)

https://github.com/flathub/org.freedesktop.Platform.VulkanLayer.MangoHud/commits/branch/25.08/ shows 3 commits two days ago, only the latest commit is actually shown in the flathub logs (client side). But this one is actually doing a full update from 0.8.2 to 0.8.3.

So I guess I am filing this issue for a regression from going from 0.8.2 to 0.8.3 with the flathub published build

[flightlessmango]

input lag is not measure by the frametime graph. I'm unclear on what the actual issue is, higher frametimes or higher input lag?
Also verify that this issue is present without lsfg-vk as it will increase your actual input lag

[SjoerdV]

Well, everything staying the same (including lsfg-vk) and the only thing different is mangohud, then the issue is definitely with mangohud. lsfg-vk is just pure genious btw, couldn't do without!

So the actual visual difference is the continuous amplitude (y axis) of the of the frame time graph depicted by mangohud, and the feeling the game feels sluggish (even when fps says it's at 120fps).

So this is the graph for a well working setup:

and the 0.8.3 update changed that to:

[17314642]

That would require manual compilation and doing commit bisecting since there've been a lot of commits between releases

[SjoerdV]

Agreed, maybe a faster cadence between releases could be contemplated in the future.

For now, let’s see if other people will upvote this issue, maybe it’s just a fluke, and for me, I have a rollback workaround. So let’s wait and see, no hurries mate!