Poor refresh rate in Jetbrains Rider while using Vulkan rendering

[ferencgyenezs]

Config

// This config is in the KDL format: https://kdl.dev
// "/-" comments out the following node.
// Check the wiki for a full description of the configuration:
// https://github.com/YaLTeR/niri/wiki/Configuration:-Introduction

spawn-at-startup "niri" "msg" "action" "focus-workspace" "work"
spawn-at-startup "vicinae" "server"

config-notification {
    disable-failed
}

gestures {
    hot-corners {
        off
    }
}

// Input device configuration.
// Find the full list of options on the wiki:
// https://github.com/YaLTeR/niri/wiki/Configuration:-Input
input {
    keyboard {
        xkb {
        }
        numlock
    }
    touchpad {
      tap
      natural-scroll
    }
    mouse {
      accel-speed -0.5
    }
    tablet {
      map-to-output "DP-4"
    }

    focus-follows-mouse max-scroll-amount="95%"
}
// You can configure outputs by their name, which you can find
// by running `niri msg outputs` while inside a niri instance.
// The built-in laptop monitor is usually called "eDP-1".
// Find more information on the wiki:
// https://github.com/YaLTeR/niri/wiki/Configuration:-Outputs
// Remember to uncomment the node by removing "/-"!


// AOC
output "PNP(AOC) U2790B 0x0000E3F3" {
  mode "3840x2160@60.000"
  scale 1.5
  position x=0 y=0
}


// DELL
output "Dell Inc. DELL S2725QS F55C364" {
  focus-at-startup
  mode "3840x2160@120.000"
  scale 1.5
  position x=0 y=1440
}

// Laptop
//output "Lenovo Group Limited 0x8A95 Unknown" {
//  focus-at-startup
//  mode "2560x1440"
//  scale 1.5
//  position x=0 y=1080
//}

cursor {
    xcursor-size 24
    xcursor-theme "Bibata-Modern-Ice"
    hide-when-typing
    hide-after-inactive-ms 1000
}

// Settings that influence how windows are positioned and sized.
// Find more information on the wiki:
// https://github.com/YaLTeR/niri/wiki/Configuration:-Layout
layout {
    // Set gaps around windows in logical pixels.
    background-color "transparent"
    // When to center a column when changing focus, options are:
    // - "never", default behavior, focusing an off-screen column will keep at the left
    //   or right edge of the screen.
    // - "always", the focused column will always be centered.
    // - "on-overflow", focusing a column will center it if it doesn't fit
    //   together with the previously focused column.
    center-focused-column "never"
    // You can customize the widths that "switch-preset-column-width" (Mod+R) toggles between.
    preset-column-widths {
        // Proportion sets the width as a fraction of the output width, taking gaps into account.
        // For example, you can perfectly fit four windows sized "proportion 0.25" on an output.
        // The default preset widths are 1/3, 1/2 and 2/3 of the output.
        proportion 0.33333
        proportion 0.5
        proportion 0.66667
        // Fixed sets the width in logical pixels exactly.
        // fixed 1920
    }
    // You can also customize the heights that "switch-preset-window-height" (Mod+Shift+R) toggles between.
    // preset-window-heights { }
    // You can change the default width of the new windows.
    default-column-width { proportion 0.5; }
    // If you leave the brackets empty, the windows themselves will decide their initial width.
    // default-column-width {}
    // By default focus ring and border are rendered as a solid background rectangle
    // behind windows. That is, they will show up through semitransparent windows.
    // This is because windows using client-side decorations can have an arbitrary shape.
    //
    // If you don't like that, you should uncomment `prefer-no-csd` below.
    // Niri will draw focus ring and border *around* windows that agree to omit their
    // client-side decorations.
    //
    // Alternatively, you can override it with a window rule called
    // `draw-border-with-background`.
    border {
        off
        width 4
        active-color   "#707070"      // Neutral gray
        inactive-color "#d0d0d0"      // Light gray
        urgent-color   "#cc4444"      // Softer red
    }
    shadow {
        softness 30
        spread 5
        offset x=0 y=5
        color "#0007"
    }
    struts {
    }
}
layer-rule {
    match namespace="^quickshell$"
    place-within-backdrop true
}
overview {
    workspace-shadow {
        off
    }
}
// Add lines like this to spawn processes at startup.
// Note that running niri as a session supports xdg-desktop-autostart,
// which may be more convenient to use.
// See the binds section below for more spawn examples.
// This line starts waybar, a commonly used bar for Wayland compositors.
spawn-at-startup "bash" "-c" "wl-paste --watch cliphist store &"

spawn-sh-at-startup "xrdb -merge ~/.Xresources"


environment {
  XDG_CURRENT_DESKTOP "niri"
  XDG_PICTURES_DIR "/tmp/screenshots/"
  //QT_AUTO_SCREEN_SCALE_FACTOR "0"
  //QT_SCALE_FACTOR "0.75"
  //QT_WAYLAND_FORCE_DPI "physical"
}
hotkey-overlay {
    skip-at-startup
}
prefer-no-csd
screenshot-path "~/Pictures/Screenshots/Screenshot from %Y-%m-%d %H-%M-%S.png"
animations {
    workspace-switch {
        spring damping-ratio=0.80 stiffness=523 epsilon=0.0001
    }
    window-open {
        duration-ms 150
        curve "ease-out-expo"
    }
    window-close {
        duration-ms 150
        curve "ease-out-quad"
    }
    horizontal-view-movement {
        spring damping-ratio=0.85 stiffness=423 epsilon=0.0001
    }
    window-movement {
        spring damping-ratio=0.75 stiffness=323 epsilon=0.0001
    }
    window-resize {
        spring damping-ratio=0.85 stiffness=423 epsilon=0.0001
    }
    config-notification-open-close {
        spring damping-ratio=0.65 stiffness=923 epsilon=0.001
    }
    screenshot-ui-open {
        duration-ms 200
        curve "ease-out-quad"
    }
    overview-open-close {
        spring damping-ratio=0.85 stiffness=800 epsilon=0.0001
    }
}

debug {
    render-drm-device "/dev/dri/renderD129"
    ignore-drm-device "/dev/dri/renderD128"
}


// Override to disable super+tab
recent-windows {
    binds {
        Alt+Tab         { next-window scope="workspace"; }
        Alt+Shift+Tab   { previous-window scope="workspace"; }
        Alt+grave       { next-window filter="app-id"; }
        Alt+Shift+grave { previous-window filter="app-id"; }
    }
}

// Include dms files
include "dms/colors.kdl"
include "dms/layout.kdl"
include "dms/alttab.kdl"
include "dms/binds.kdl"
include "dms/dms_binds.kdl"
//include "noctalia/binds.kdl"

include "dms/cursor.kdl"
include "workspace.kdl"
include "dms/outputs.kdl"

include "own_layout.kdl"

include "dms/windowrules.kdl"

System Information

• niri version: niri 25.11 (v25.11-189-ge9c182a1) This is a recent main build, but I have the same issue with stable

• Distro: Fedora 43 (KDE)

• GPU: NVIDIA GeForce RTX 3060 Mobile / Max-Q [Discrete]

• CPU: AMD Ryzen 9 5900HX (16) @ 4.68 GHz

• Laptop: Lenovo ThinkBook 16p Gen 2

Disclaimer:

• Currently, my laptop is using only the Nvidia card; iGPU is disabled.
• I also used the card in "boosted" mode. I've maxed out the clocks (gpu, mem). What you see here is not GPU lag or slow-reacting performance levels.

The problem: I've been using Rider with Wayland for a while now, but as it turns out, if you do that, the IDE is still doing software rendering. Which means every UI interaction is generally pretty slow, but bearable.

This command enabled Wayland: Dawt.toolkit.name=WLToolkit

This command enables Vulkan rendering: Dsun.java2d.vulkan=True

My Rider's logs:

2026-04-23 18:48:07,612 [    214]   INFO - STDERR - Vulkan rendering enabled: YES
2026-04-23 18:48:07,612 [    214]   INFO - STDERR -   Presentation enabled: YES
2026-04-23 18:48:07,612 [    214]   INFO - STDERR -   Accelerated surface data enabled: YES
2026-04-23 18:48:07,612 [    214]   INFO - STDERR -   Devices:
2026-04-23 18:48:07,612 [    214]   INFO - STDERR -     *0: NVIDIA GeForce RTX 3060 Laptop GPU
2026-04-23 18:48:07,612 [    214]   INFO - STDERR -      1: AMD Radeon Graphics (RADV RENOIR)
2026-04-23 18:48:07,612 [    214]   INFO - STDERR -      2: llvmpipe (LLVM 21.1.8, 256 bits)

To be fair, Vulkan rendering is currently beta: https://youtrack.jetbrains.com/issue/JBR-7558/WLToolkit-Vulkan-rendering-pipeline
And I think Wayland became the default with 2026.1

My problem:

If Vulkan rendering is enabled, and if I have more than one Rider instance running on the same display, when switching between these instances, there is a 5-7second time frame when the IDE is unusable, you can't scroll, barely can interact with anything.

In my demo, this issue is a bit extreme because Instance1 has this 5-7sec unusable period, but Instance2 is permanently slow. This Instance2 behavior is not always true, mostly behaves like I1, so it is slow for the first 5-7 seconds.

If I move Instance2 off to my second screen, everything is fine on the recorded display, but the moment I bring it back to the main screen, the issue is back.

One important thing: I don't have this issue with KDE, I'm doing the same test, on the same laptop, same boosted Nvidia card.

Video demos:

https://gofile.io/d/JDL7yc

niri_rider.mp4

• I'm furiously scrolling up and down all the time. If nothing seems to happen on the screen, it's because Rider is not rendering/updating.
• If only one instance of Rider is running + Btop, I can switch between them freely, and Rider never lags
• The moment I move Instance2 to the same monitor, everything lags, including switching between Rider and Btop.
• And to give all this a nice twist, the moment both Rider instances are visible, the issue is gone.
• You can see it in BTOP, that when switching between applications, both CPU and the GPU don't ramp up. I'm not sure who to blame in this case. Normally, I would blame the CPU for not providing work to the GPU. In KDE both react immediately.

kde_rider.mp4

• it just works

I did the same test on my desktop, which has a 5070Ti, no iGPU, runs on the stable niri version, and behaves exactly the same.

To be clear, I'm not sure if this has anything to do with niri, or maybe it is Rider, but KDE doesn't have this problem.

[Sempyos]

Please replicate on sway and cosmic-comp

Attempt replicating with the iGPU

[ferencgyenezs]

Hi

Cosmic:

https://gofile.io/d/Nx2AfB

Works just fine with Nvidia. I also tested it with the iGPU, and there is no lag, but due to the low performance of the iGPU everything is pretty choppy.

Sway:

• iGPU only: no issue, just general slowness

Niri:

• iGPU only: no issue, just general slowness

-Dsun.java2d.vulkan.deviceNumber=1

With this command, you can control which GPU will be used by the IDE. You can see the IDs in the idea.log file.

Edit:

I just noticed that, if Rider is rendered with iGPU, my Nvidia card is running at 66-70% utilization.

To be clear, I'm not using the laptop's screen, but two external 4k monitors. So there is a lot of coping between the GPUs. Nvidia driver is not even good at this on Linux.

igpu_rider_and_niri.mp4

With obs recording the dGPU is maxxed out.

[Sempyos]

I would assume this is just an Nvidia driver issue which would not be our issue, or a duplicate of this: #3562

[mati865]

Considering this works with all other compositors (including Cosmic) so far, saying this is not a Niri issue seems a bit hastily.

[Sempyos]

@ferencgyenezs I'm assuming it's fine without vulkan..? And does it work fine with vulkan on xwayland..?

[bczhc]

My tests are the same as op's.

Jetbrains IDEs with Vulkan enabled are very laggy on switching between windows/selecting multiple lines then scrolling, when multiple project windows are opened; if they're displayed within the same screen (e.g. side-by-side aka. 50%-50%, it's fine), however 100%-100% causes the lag.

When the lag happens, no significant overload is observed for CPU %util, GPU %util, GPU PCIe Rx/Tx.

I'm assuming it's fine without vulkan

Yes. Removing -Dsun.java2d.vulkan=True solves it.

And does it work fine with vulkan on xwayland

Yes. and this won't happen with the iGPU. That is:

• VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json rustrover lags.
• VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.json rustrover doesn't lag.
• unset WAYLAND_DISPLAY; VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json rustrover doesn't lag.
• unset WAYLAND_DISPLAY; VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.json rustrover doesn't lag.

edit: ah yea Vulkan only works when Wayland is active. Confirmed that using the mangohud layer (MANGOHUD=1 env).

Won't happen on Hyprland and cosmic-comp. But Hyprland has this: hyprwm/Hyprland#13346 and its fix, not sure if this yields any clue.

[ferencgyenezs]

@Sempyos

@ferencgyenezs I'm assuming it's fine without vulkan..? And does it work fine with vulkan on xwayland..?

Yes, the lockup doesn't happen, but it also feels like 20fps. Imo Vulkan rendering only works when Wayland (WLToolkit) is active, so with XWayland the Vulkan flag does nothing.

@bczhc
Thanks for verifying it!

[Sempyos]

Thanky both of you

[Sempyos]

I would be genuinely curious if someone with an AMD GPU is able to replicate this issue too

[Naharie]

Just tried on a laptop with an AMD APU and I can't replicate this issue. Multiple instances whether visible together (50%-50%) or not (100%-100%) don't seem to change anything. I do, however, get a very different bug. Scrolling is fast and smooth, but slams the GPU. The longer you scroll the more of the GPU you use. Where it does lag is when you scroll to the top or bottom of a file. Curious.

Edit: Turns out top and bottom are only special in that they tend to change the context display at the top. Not sure what you call it, but the thing that shows which class and method you are inside of.

[mati865]

I can reproduce the issue in Cosmic desktop (Nvidia GPU obviously) by placing two maximised (non-fullscreen) RustRover instances in separate workspaces.
When I scroll a lot in the first instance, quickly change to the other workspace and start scrolling, it is as unresponsive as when using Niri.

[Naharie]

This is almost certainly an nvidia problem. On an AMD APU I forced Rider to use the latest vulkan package for my distro and that fixed the lag. It still eats unreasonable amounts of gpu compute, though. Anyone who can test on an nvidia card, what is your driver number? Version 596.36 seems to still have certain vulkan regression, which, curiously enough, cause bad frame pacing in certain situations. Some hotfixes were released since 596 to theoretically fix it, but a fair number of people on reddit and forums have found that the fix didn't work for them.

1. nvidia forum
   1. Early on a user claims that everything since 591.86 is broken for them
2. Unanswered question - older version but other places say the issue has persisted through the later patches and do mention all of them as being affected
3. Flight simulator forum - need to scroll down a bit to find people with the problem
   1. Some people there mentioned DLSS as a possible problem, but elsewhere people seem to have the problem in places where DLSS would not be running anyway.
4. Oh, and a Minecraft bug about lag only with vulkan on wayland
5. Pop OS! might also use smithay? Not sure without reading their code, so both cases might be the same.
6. Smithay Issue with SMH buffers
   1. The Smithay issue seems to be tied to nvidia as well.

For some reason the Islands theme causes extra CPU and GPU work over the old themes. Maybe that's just my system being weird, but maybe somebody else can test on nvidia if switching to an old theme through the launcher either avoids or makes the glitch less bad?

[mati865]

Latest Nvidia Linux driver is 595.71.05 which is the one I'm using. Half of your links are related to Windows driver specifically.

Pop OS! might also use smithay? Not sure without reading their code, so both cases might be the same.

Did you mean Cosmic? If so, then yes, it's also based on smithay.

so both cases might be the same.

That's exactly what we are trying to pinpoint.

I'm hoping that somebody who has other compositors set up (and Nvidia GPU), will try my steps and report back.

For some reason the Islands theme causes extra CPU and GPU work over the old themes. Maybe that's just my system being weird, but maybe somebody else can test on nvidia if switching to an old theme through the launcher either avoids or makes the glitch less bad?

Normal Dark theme works much worse than Islands Dark in regard to this bug. With single instance the difference is hardly noticeable, but my CPU spiked little less on the chart with Islands. Though, the difference was definitely within noise margin.

[ferencgyenezs]

Since this issue is my only pain point with Niri, I had to do something about it. So this week, I decided to do the most sensible thing and gave Claude the task to fix this issue.

Quick recap:

If both Rider instances are visible, the performance in both is fine:

sidebyside-stock.mp4

But the moment I switch both instances to full screen, the first one is fine after a while, but the second instance never recovers. Interestingly enough, in my original videos, the second instance would recover and render just fine after 10 seconds. In this demo, it is stuck at 1 fps.

fullscreen-stock.mp4

Finding the fix took some iteration, and honestly, I'm not really confident if this is THE fix, since I have no Wayland compositor experience.

the-fix.mp4

fix branch: https://github.com/ferencgyenezs/niri/tree/%233890-poor-refresh-rate-in-jetbrains-ide-with-vulkan

The README.md explains everything in great detail. Mainly because I also had to understand how the compositing pipeline works.

The branch includes two fixes:

• Explicit sync (wp_linux_drm_syncobj, committed in d5b8576b) gives NVIDIA proper release fences → swapchain images get freed → the client can actually acquire and render. Fixes the buffer half.
• Fast, continuous fallback frame callbacks (the timer change) feed the blocked Vulkan WSI thread callbacks at a high rate regardless of whether the window committed damage. That breaks B out of the reveal trap: B's present thread unblocks, presents a real frame, which produces damage, and from there the normal redraw→callback loop can sustain itself. Fixes the pacing half.

I don't think that the "Fast, continuous fallback frame callbacks feed regardless of whether the window committed damage" is the right way to go. Mainly because surely you waste compute cycle on windows that are not in focus. Hence, we only give them a callback every 1Hz. Implementing Explicit sync is not enough. Not to mention I don't know, 1. why this is not implemented to begin with, 2. if the implementation is good or not. But one thing is for sure: to make this "fix" work, I needed both.

[bczhc]

@ferencgyenezs Your investigation gives a hint! Because of this defect I've disabled my Jetbrains Vulkan rendering mode. But now after rereading it I suddenly am feeling this has something to do with #1525 (and its pr).

I tested #2609 and surely, it does fix it. Just enable force-render for jetbrains windows.

window-rule {
    match app-id=r#"^jetbrains-.*"#
    force-render true
}

Also I tested your patch and yes it also enables "force rendering" for background applications - anyway but, it breaks Vulkan's fifo present mode (aka. vsync) and makes apps consume unneeded GPU. If mangohud is installed, test it using MANGOHUD=1 vkcube or with VK_PRESENT_MODE_FIFO_KHR explicitly specified: MANGOHUD=1 vkcube --present_mode 2 and it's expected to see the framerate = your monitor refresh rate but now it's not.

[ferencgyenezs]

@bczhc

it breaks Vulkan's fifo present mode (aka. vsync) and makes apps consume unneeded GPU.

Honestly, I would be surprised if it works flawlessly.

Thanks for mentioning #2609, I will keep an eye on it, also I've switched over to this patch.

[Sempyos]

So is just a thing that needs the force render and fifo PRs..? Just making sure I'm reading this correctly

[bczhc]

Yea I confirmed just #2609 + enabling force-render for jetbrains apps solve the issue. There's nothing related to fifo present mode here. If a GPU program has its "render attachment" surface configured as "fifo present mode" (e.g. Vulkan's VK_PRESENT_MODE_FIFO_KHR or wgpu's wgpu::PresentMode::Fifo), it should sync with the monitor refresh rate no matter it's fullscreen or not. I just meant that ferencgyenezs' attempt to fix breaks this. Though I don't know why this issue is nvidia-specific..

[bczhc]

wgpu-multiwindow.mp4

I wrote a wgpu program to demonstrate the similar case. The two windows share the same event loop and they both render a stripe animation. If any of them goes outside the viewport then it only has frame callback @ 1Hz thus even the visible window gets capped at 1Hz. force-render fixes it. This demo program shows the issue on both Nvidia and Intel GPU, though.

[Sempyos]

Would anyone be against me closing this issue as a duplicate of #539 ..?

[bczhc]

Sounds fair and I've tested sway and cosmic one more time and am able to reproduce the issue on them (put jb windows in different workspaces. But for me, only with NVIDIA DRM device explicitly specified, see below for details). Though idk if #539 is the final root cause to be blamed but at least a force-render is a workaround.

I have an intel+nvidia hybrid GPU + external monitor setup and can only reproduce this issue with an explicit drm render device specified: e.g. for sway it's WLR_DRM_DEVICES=/dev/dri/card1 sway --unsupported-gpu, or for cosmic it's COSMIC_RENDER_DEVICE=card1 (note this should be in /etc/environment; COSMIC_RENDER_DEVICE=xxx cosmic-session won't work). Otherwise, if nvidia drm-device not set, the issue cannot be reproduced. For example in this case, windows in a different workspace also won't render (or render at 1Hz), but there's no such issue for Jetbrains apps. This is interesting.

Maybe we can transfer it to a discussion then. This is more like an application+nvidia-specific problem.

[Sempyos]

Ya, a discussion is probably better

[Sempyos]

Done, and thanky to both of you for figuring out this issue, definitely a little bit of a weird one