[Bug] Cursor lags during smooth transitions

[ItsLemmy]

I'm on niri and I experience heavy lag during the progressive fade.

I'm not sure if it's a compositor issue or a sunsetr issue.
The weird thing is I also experience the same lag with "gammastep" but it's very smooth with wlsunset.
I tried playing with update_interval by using lower or higher value but it does not make a difference.

On my laptop with a 60Hz display its less noticeable.
On my desktop with a 144Hz display it is very laggy, can't really use the mouse during the fade animation.

I have attached a video to illustrate the issue.
https://github.com/user-attachments/assets/21186aa6-c524-4cf0-9966-9f133b4b52fc

Hope this get improved so I could replace wlsunset in our shell https://github.com/noctalia-dev/noctalia-shell

Thanks!

[psi4j]

Hi @Lemmy-Cook. It appears you're referring to the startup_transition. This setting creates a fast, smooth transition between your configured day temp/gamma to the current interpolated values as per the config. That is, if it's night, it'll transition quickly to night values on startup. I don't believe wlsunset has this functionality, which is probably why it never lags on you. You can disable this feature by setting startup_transition = false in sunsetr.toml, or you can shorten it to the default of 1 sec.

What you're experiencing appears to be a combination of your hardware's capabilities and the compositor's capabilities when applying fast, subsequent gamma changes using wlr-protocols' wlr-gamma-control-unstable-v1. Maybe when they change it from unstable to stable it'll be smoother. I do notice that using the Wayland backend is exceptionally slower on Hyprland than on niri, so I think you may be right. This could be a compositor thing as well.

The startup_transition is supposed to calibrate itself to your hardware's capabilities using an adaptive interval that uses an exponential moving average of the measured latency in milliseconds. You said your display is 60Hz on your laptop and 144Hz on your desktop. 144Hz running slower makes sense because it should be more intensive on your GPU or iGPU. What type of hardware are you running? You're not running NVIDIA by chance, are you? If you could, please provide me with as much relevant detail about your build and maybe we can figure this thing out.

[ItsLemmy]

I'm running an AMD build with 9950X CPU paired with a 7800XT. I also game on this system without any issue.

 O---o  ⬤   Distro: CachyOS x86_64
  O-o   ⬤   Kernel: Linux 6.16.4-4-cachyos
   O    ⬤   Uptime: 27 seconds
  o-O   ⬤   OS Age: 517 days
 o---O  ⬤ Packages: 1491 (pacman), 8 (flatpak)
 O---o  ⬤ Terminal: ghostty 1.1.3-arch1.1
  O-o   ⬤    Shell: fish 4.0.2
   O    ⬤       WM: niri (Wayland)
  o-O   ⬤      CPU: AMD Ryzen 9 9950X (32) @ 5.76 GHz
 o---O  ⬤      GPU: AMD Radeon RX 7800 XT [Discrete]
 O---o  ⬤   Memory: 2.18 GiB / 46.59 GiB (5%)
  O-o   ⬤     Disk: 229.20 GiB / 914.51 GiB (25%) - btrfs
   O    ⬤     Disk: 1.13 TiB / 1.79 TiB (63%) - ext4
        ⬤     Disk: 1.05 TiB / 1.79 TiB (59%) - ext4

[psi4j]

I also game on this system without any issue.

The issue is that the compositor's implementation of wlr-gamma-control-unstable-v1 doesn't have the same optimizations that a gaming engine does, especially when using higher refresh rates like 144Hz. This effectively tells the compositor to change every single pixel on your screen simultaneously, as fast as your computer can handle it (up to the refresh rate) for the duration of the startup transition.

When I say "a combination of your hardware's capabilities and the compositor's capabilities when applying fast, subsequent gamma changes," I'm not implying a limitation of the hardware, what I'm saying is that the refresh rate, along with the compositor's optimizations affect the way using wlr-gamma-control-unstable-v1 handles rapid changes.

I would like to solve this issue as well. It seems wlsunset solves it by not doing smooth interpolation at startup. sunsetr has this option as well.

So right now, we have a tradeoff:
Making less gamma updates during the window means no choppiness with the mouse, but it means less smoothness for the transition from day values to night values.

What you could do for now:
Use a keybind to toggle startup instead of a button (move attention away from mouse), shorten the startup_transition_duration to 1 sec, and maybe use a notification or icon to reflect the change (move attention away from mouse).

What I can do:
I can look at finding a way to create additional optimizations like trying to find a way to sync to the monitor's refresh rate (not sure how viable this is and there's no certainty this would fix mouse lag), making the update rate for startup transitions configurable, and making the duration configurable in milliseconds to allow sub-second configuration (something like 500 or 750 ms).

Do you have any ideas? You might be the right person to talk to for our upcoming IPC implementation for interoperating with shells like your own. I'll need user feedback when I start working on that in the not-so-distant future.

[ItsLemmy]

For us, the main incentive to switch from wlsunset was to enjoy the smooth startup transition.

I don't want to set startup_transition_duration to a low value, as it defeat the point. IMO the default should be around 5 sec.

I still dont get why the update_interval is not applied to the startup_transition, maybe that would be a first thing to investigate/implement ? I think transitioning with a refresh at 30Hz would be good enough in most cases.

[psi4j]

I still dont get why the update_interval is not applied to the startup_transition

The update_interval is for the regular transitions. This is configurable from 10-300 sec. I chose not to make this apply to the startup transitions because applying this same parameter to a short startup transition isn't optimal, given that the sunset/sunrise transitions happen over a duration from 5 min to 2 hours and a startup transition should be rather quick. Performing smooth interpolation across shorter windows requires more updates to make changes not noticeable. The longer the transition duration, the more time you can add to the update interval without affecting perceivable smoothness.

What I can do is make the startup transition's update interval also configurable. I'll check out how things look at 30Hz as well, maybe this will be sufficient.

[ItsLemmy]

Sounds like a plan, looking forward to it!

[psi4j]

I've played around with this some more, and I'm realizing there are to potential ways to optimize smoothness on my particular build (this will likely be idiosyncratic to your system):

1. Cut the duration of the transition to about 0.5 sec and minimize update interval duration (I used 1ms, but the adaptive interval EMA will find your build's optimal update interval). This does a quick fade that minimizes time that the mouse is affected to be negligible unless you're using a button and need to instantly move it. Looks much better than a jarring instant temp/gamma switch.

2. Extend the time and the update interval. I found that a 5 sec duration and about a 130ms update interval smooths this out fairly well. This is a good balance between the smoothness of the temperature change and the smoothness of the mouse movement. This could be different on your build and will likely require fine tuning for various different builds.

If you're looking to really smooth things out, you can make the startup transition last something like 30 sec. You will have no issues with smoothness then. I'll release this new configuration capability on the next release, which shouldn't be too far away. I've got few more features to add. If you can think of anything else, let me know.

[ItsLemmy]

For our specific use case I would love to be able to call sunsetr with an inline config, so that it ignores the default toml file ( ~/.config/sunsetr/sunsetr.toml) and rather read the config as a string passed as an argument.

Maybe something like sunsetr --toml "day_temp=6500\nnight_temp=3300\nlatitude= ....

Either this or add a bunch of options to be able to control the basic parameters from the command line.

Thanks!

[psi4j]

I've got something I'm about to release that solves this exact problem by enabling toggle-able presets (see #16). You'll be able to call user-defined presets by name instead of a bunch of parameters inline. Run the same preset name twice and it'll switch back to default config:

1. sunsetr -> night
2. sunsetr preset day -> static day values
3. sunsetr preset day -> back to regular config (night).
4. sunsetr p weekend -> weekend schedule using "finish_by" at 11:30PM
   etc

You'll be able to use shell scripting to do all kinds of conditional stuff, set up toggle buttons, keybinds, etc.

[ItsLemmy]

Cool ! Ideally I still need control on color temperatures and sunrise and sunset time. for reference here is the settings we have implemented in the current version of Noctalia.

[ItsLemmy]

So to sum it up, we would like control via CLI on the following params

Night Color Temp
Day Color Temp
Latitude
Longitude
Sunrise Time (when not using Latitude/Longitude)
Sunset TIme (when not using Latitude/Longitude)

[psi4j]

So to sum it up, we would like control via CLI on the following params

I see. The inline config is a feasible solution, though making the configs (including presets) hot-reloadable might also be viable. Let's open a separate issue for this one and continue the thread there whenever you're ready. You're thinking outside the box, I like the idea.

[psi4j]

So, I was testing some of the new features on an old laptop that doesn't have a GPU and I noticed there is zero mouse lag on Hyprland, but there is still some mouse lag on niri. When performing the same test on my builds with GPUs, the mouse lag is minimal, but happens on both compositors. There might be some clue as to what Hyprland might be doing with CPU rendering on an old intel chip that is different from what it does when it runs with a GPU.

I know that this issue largely has to do with the way the kernel handles the gamma changes requested by the compositor. @Lemmy-Cook if you do have any PCs without a GPU and you have a moment, could you try testing to see if the mouse lag happens when you use Hyprland?

For me, using Hyprland with CPU rendering with EITHER backend fully eliminates the mouse lag. I am thoroughly confused, but it is a good starting point for doing some further investigation on this issue.

[ItsLemmy]

Yep, I should be able to test it fairly soon. Right now can't install hyprland on cachy, a package is 404.

[ItsLemmy]

Can confirm that on my old laptop (Intel HD Graphics 620) :

• no lag at all during fading on hyprland
• minimal lag during fading on Niri (acceptable)