Continuation of discussion for zoom/magnifier interface and impl in #3246

[Atan-D-RP4]

Summary:

The PR in the title (#3246) is an implementation of zoom/magnification for Niri.

It uses the same pipeline as the overview pan out. Basically, I pass all the render elements through a zoom transform, and added new variants to niri_render_elements! macro to generate Into impls for the appropriate variants on that type.

The PR got a lot of traction, discussion and feedback. It's over 100 comments now! So I brought the discussion over here now.

[Atan-D-RP4]

Having done some more quick research, here's a new design for the interface on bind/ipc-action side:

niri msg action set-zoom-state --<param> <change> <option<output_name>>

IPC actions do tend to take -- args, so I think this fits. Problem with it though, is that the actions also usually never return any state.

So you will still have pass queries through the old interace.

[Atan-D-RP4]

Just pushed another patch on the PR that implements the zoom center-lock. I call it freeze now, because... I started with that when it was mentioned in the PR thread and didn't get around to changing it.

Usage:

output "<name>" {
   zoom {
     freeze // locks the zoom-center/viewport so cursor is free to explore
   }
}

niri msg output <name> zoom freeze true|false

I don't know when I'll get to this: niri msg action set-zoom-state --<param> <change> <option<output_name>> though. Since with this, the PR is mostly feature complete (unless someone chimes in with another great QoL feature or makes a good case for one).

[Axlefublr]

Currently, niri actions tend to be quite granular.
I'm looking at niri msg action --help, and noticing these two immediately: power-off-monitors and power-on-monitors.
You'd think that it would combine the two, being just power-monitors that would take true or false or something;
This pinpoints that niri, as a design decision, likes to provide more granular and small actions.
Rather than “change something about zoom”, it would be set-zoom-factor, ... I would provide more examples but honestly I forget what else you might even need / want to change about zoom. I think I only care about the factor?

More examples to drive my point home:
screenshot, screenshot-screen, screenshot-window instead of just screenshot with optional screen/window arguments.
The whole array of actions that start with focus-window- — they are hyperspecific and there is like a billion of them: focus-window, focus-window-in-column, focus-window-previous, focus-window-or-monitor-up, focus-window-or-monitor-down, focus-window-down, focus-window-up, focus-window-down-or-column-left, focus-window-down-or-column-right, focus-window-up-or-column-left, focus-window-up-or-column-right, focus-window-or-workspace-down, focus-window-or-workspace-up, focus-window-top, focus-window-bottom, focus-window-down-or-top, focus-window-up-or-bottom

Also, I think toggling zoom freeze should be an action, rather than an output thing. My reasoning: all of the actions under niri msg output imply some sort of long-termness.
off, on, mode, custom-mode, modeline, scale, transform, position, vrr
You usually call them to do some “finalistic” action. Changing an option that you're going to be using for a while, if not forever / until logout.

Freeze, on the other hand, is very action-like — you toggle it because you want to use it for probably just a few seconds, and then toggle it off. As opposed to it being a setting that you enable and then stick with for a while because you prefer it.

Unless I misunderstand how the freeze feature works. I'm on an old-ish commit of the pr, as I'm currently more satisfied with it than with the current iteration, when it comes to the ipc. And so I might be talking out of my ass above.

[Atan-D-RP4]

I can see where you're coming from about niri allowing granular actions. And yeah, the config options do seem a bit bloated. There is such as thing as too much configurability. Maybe instead of making it all per-output, I should make just zoom factor per-output and let everything else be set via a new namespace in zoom {} or magnification {}.

But about niri msg output, I disagree about them being for finalistic action, it's help literally says 'Change output configuration temporarily'. Though that begs the question, would changes to output config made like that survive config reload (for users who do dynamic theming)? I think not, so decoupling from that seems a good idea in general.

How does this look then?

cursor {
   scale-with-zoom
}
zoom {
   default-factor 1.5
   movement "cursor-follow" // or "edge-pushed"
   threshold 0.05 // 0 to 1 float
}

niri msg action toggle-zoom <option<output_name>>
niri msg action toggle-zoom-freeze  <option<output_name>>
niri msg action set-zoom-factor <float_or_int>  <option<output_name>>
niri msg action set-zoom-movement <change>  <option<output_name>>
niri msg action set-zoom-threshold <float_or_int>  <option<output_name>>

For queries

niri msg focused-output
Output "Chimei Innolux Corporation 0x1406 Unknown" (eDP-1)
  Current mode: 1920x1080 @ 60.002 Hz (preferred)
  Variable refresh rate: not supported
  Physical size: 310x170 mm
  Logical position: 0, 0
  Logical size: 1280x720
  Scale: 1.5
  Transform: normal
  Zoom:
    Factor: 1.5
    Movement: cursor-follow
    Threshold: 0.01 or 1%
    Frozen: true
  Available modes:
    1920x1080@60.002 (current, preferred)
    1920x1080@40.002

Or maybe this:

niri msg zoom-state
    Factor: 1.5
    Movement: cursor-follow
    Threshold: 0.01 or 1%
    Frozen: true

Freeze, on the other hand, is very action-like — you toggle it because you want to use it for probably just a few seconds, and then toggle it off. As opposed to it being a setting that you enable and then stick with for a while because you prefer it.

Unless I misunderstand how the freeze feature works. I'm on an old-ish commit of the pr, as I'm currently more satisfied with it than with the current iteration, when it comes to the ipc. And so I might be talking out of my ass above.

That's my bad. I didn't mention the niri msg action toggle-zoom-freeze also works.

[Axlefublr]

Yeah, I like the idea of a zoom section, that applies globally to every output, instead of having to configure it separately per each. But more importantly than what I like, I think it makes more sense too: in no world will someone prefer cursor-follow on one monitor, but edge-pushed on another. I say this in fear of the Usecase Man™ appearing, but I feel this is super reasonable to not anticipate.

The default-factor is to make toggle-zoom useful when you haven't yet changed your zoom factor, right?
It seems oddly specific to me. Considering it's easily achievable with a script that gets the current zoom factor, sets it to 1 if it's not one, and sets it to the user's prefered value if it is 1.
I.e., I see this as userland type of feature. In that same breath, I wonder if having toggle-zoom in core even makes sense.
This is in continuation to the thought of “sometimes things are too configurable”.

Change output configuration temporarily

I guess so, but even still, freezing zoom sounds to me more like an action you are doing, rather than changing your monitor's configuration. You are operating on a feature of the compositor, rather than a feature of your monitor, is how I would put it.
The feature just happens to occupy the monitor space, but semantically it's more like an action within the feature.

I wonder if set-zoom-movement and set-zoom-threshold should even exist, actually. To me they seem like things you set once in your config, and then never again touch. But maybe that's just me.

Queries look fantastic 👍

Ah nice, there's an action for it too? In that case, is there a need to duplicate it under output? I don't remember niri ever putting the same functionality in two places.

[Atan-D-RP4]

The default-factor is to make toggle-zoom useful when you haven't yet changed your zoom factor, right? It seems oddly specific to me. Considering it's easily achievable with a script that gets the current zoom factor, sets it to 1 if it's not one, and sets it to the user's prefered value if it is 1. I.e., I see this as userland type of feature. In that same breath, I wonder if having toggle-zoom in core even makes sense. This is in continuation to the thought of “sometimes things are too configurable”.

I think it does make sense, since I see this zoom as a natural progression of the overview-pan-out. Although I made the toggle because changes to the state also caused zoom to trigger in my earlier testing so I just put it behind a flag.
It'll probably end up get axed in review.

I guess so, but even still, freezing zoom sounds to me more like an action you are doing, rather than changing your monitor's configuration. You are operating on a feature of the compositor, rather than a feature of your monitor, is how I would put it. The feature just happens to occupy the monitor space, but semantically it's more like an action within the feature.

I do agree with that, and that's how I wanted to implement it too, but the flow of data from IPC to Niri's internal output state posed some challenges so I ended up with what I have which I deferred on cleaning up while testing. I probably won't until this gets review by someone who's worked on extending the IPC.

I wonder if set-zoom-movement and set-zoom-threshold should even exist, actually. To me they seem like things you set once in your config, and then never again touch. But maybe that's just me.

Seems reasonable, until Usecase Man™ appears of course.

Queries look fantastic 👍

Ah nice, there's an action for it too? In that case, is there a need to duplicate it under output? I don't remember niri ever putting the same functionality in two places.

It does not, as far as I know. I just ended up with both in for when I was testing.

[Atan-D-RP4]

Would you also want an IPC event for zoom state changed? It would defined like:

enum Event {
   ...
   ZoomStateChanged {
      output: String,
      change: ZoomState,
   }
}

[Atan-D-RP4]

Well it's available in the latest patch now.

[Axlefublr]

oooooh that's fantastic! I don't have a usecase for it currently, but definitely see it being useful. not a bloat addition either imo 🧐

[SergeGris]

It's awesome! And it's works very fine. But there are things worth paying attention to:

1. Make it work with recording tools (I've tried to record my experience with it, but on recording no zoom visible), it could be pretty nice to keep some flag to control such behavior, but idk whether it's useful for anybody
2. Working with multi-monitor setup would require some discussion about how should it work. Zoom all monitors by default? Zoom only focused one? Make cursor linked to zoomed monitor until zooming back (awful, but maybe)? Would be nice to look how it is implemented i.e. by Hyprland.
3. Animated zooming in/out? It would be probably pretty hard to implement, but without smooth zooming it looks pretty foreign, since other niri features uses animations
4. Cursor behavior seems to be pretty inconsistent, when monitor is zoomed in, cursor behaves like it is shifted a bit, so when i.e. selecting text it starts select by one letter further than expected

[SergeGris]

Also I've got no idea how to bind kinda iterative zooming to mouse wheel with zooming in and out smoothly, Seems that it require toggle-zoom and then increase zoom step by step, but can I set zoom and unset zoom? Also can I just increase zoom factor to get my monitor zoomed without calling toggle-zoom?

[Axlefublr]

I think indeed you can just increase the zoom factor and it'll do its thing. toggle-zoom is not required

[Atan-D-RP4]

toggle-zoom is actually required right now. Though I think I'm gonna remove this and the default-factor, since you don't really want to be setting the zoom factor and not, you know, zooming and not having the toggle also removes the need for a default.
So that's fewer configs and actions to manage.
toggle-freeze is here to stay though

[Atan-D-RP4]

It's awesome! And it's works very fine. But there are things worth paying attention to:

1. Make it work with recording tools (I've tried to record my experience with it, but on recording no zoom visible), it could be pretty nice to keep some flag to control such behavior, but idk whether it's useful for anybody

I didn't expect that to break. If you see the demo video on the tracking issue for the PR, I have a recording of the zoom working.
Many people also submitted recordings on the PR comments as feedback.
Will test it again.

2. Working with multi-monitor setup would require some discussion about how should it work. Zoom all monitors by default? Zoom only focused one? Make cursor linked to zoomed monitor until zooming back (awful, but maybe)? Would be nice to look how it is implemented i.e. by Hyprland.

It's already per-monitor. Please check the PR comments for the discussion on that. More feedback is welcome!

3. Animated zooming in/out? It would be probably pretty hard to implement, but without smooth zooming it looks pretty foreign, since other niri features uses animations

I'm seeing about that.

4. Cursor behavior seems to be pretty inconsistent, when monitor is zoomed in, cursor behaves like it is shifted a bit, so when i.e. selecting text it starts select by one letter further than expected

Fixed!

[Atan-D-RP4]

I think I'm gonna remove the entire zoom {} block too. Nobody cares enough about default zoom factor, threshold isn't really too customizable since there's only a few good values for it. For movement, we can probably throw it into a misc option like prefer-no-csd or something.

We'll still have cursor { scale-with-zoom }

For IPC, we will:

niri msg action set-zoom-factor <float_or_int> <option<output>>
niri msg action set-zoom-movement <name> <option<output>>
niri msg action toggle-zoom-freeze <option<output>>
niri msg --json zoom-state <option<output>>
{factor: float_or_int, movement: "cursor-follow|edge-pushed", is_locked: bool}

[Axlefublr]

I wonder if we should just set the threshold to always keep the cursor in the middle of the screen. Selfish, I know, because that's the behavior I happen to want. But I feel like it's more wieldy anyway. If you're thinking of axing the threshold.

This ipc I like more indeed! Still iffy about movement being not exclusively a config option. But I think I already expressed myself on that point.

toggle-zoom not existing and more crucially not being required to change my zoom, will be incredible usable!

[Atan-D-RP4]

I wonder if we should just set the threshold to always keep the cursor in the middle of the screen. Selfish, I know, because that's the behavior I happen to want. But I feel like it's more wieldy anyway. If you're thinking of axing the threshold.

Isn't that just cursor-follow then?

This ipc I like more indeed! Still iffy about movement being not exclusively a config option. But I think I already expressed myself on that point.

It might be. But since it's the only configurable zoom option, having another zoom {} namespace just seems a waste. prefer-no-csd and others survive being solo just fine. I am a bit torn on the name though. Is just edge-pushed-zoom fine?

toggle-zoom not existing and more crucially not being required to change my zoom, will be incredible usable!

Yep!

[Axlefublr]

ohhhh, I thought threshold applied to cursor-follow for some reason. cursor-follow now works with the cursor centered by default? nice :D

zoom-edge-pushed should be better. or maybe zoom-movement: "edge-pushed"

[nickjj]

I have a suggestion that I didn't see discussed yet in the PR:

What do you think about dynamically changing the mouse sensitivity based on the zoom level so that your "perceived" mouse sensitivity is kept consistent? Typically when you zoom in, your perceived sensitivity is much higher. This feature could help you get fine grain control to click something specific if you use high sensitivity.

[Atan-D-RP4]

I think someone did mention something like this in the PR thread.

I didn't touch on it because, I didn't know how pointer motion was handled before. Having banged my head against it to get edge-pushing working, it's now broken again by the way, I think I'll take a gander it.

[Axlefublr]

I didn't wanna mention it for bloat reasons, but GOD it would be INCREDIBLE. I often use the zoom feature for design, where being able to slowly look at pixels is very helpful. in woomer, this was easy and pleasant to do. But in this zoom pr, the cursor feels a lot more unwieldy. Understandably so, mind you — it's not a surprising behavior, but still quite uncomfortable.

The mouse speed scaling with the zoom level would remove the need for toggle-freeze for me, for instance.

Good luck with it, atan d goat!

[garfunkel]

Not sure if it's something others have experienced, but with the recording-while-zoomed thing, I guess that's the same behaviour you get when you share your screen over a tool like MS Teams or Slack or Zoom or whatever. For work, whenever I need to demo something on my screen (not using Niri currently), I normally make sure I'm zoomed out beforehand, so as not to disturb/confuse anyone watching the feed, as they wouldn't be expecting the magnification in order to see what's on the screen like I would.

[Atan-D-RP4]

@zgibberish
I updated the PR branch with some more fixes.
I actually implemented the logarithmic increments instead of just putting together the scaffolding(true derp). Fixed the viewport not updating on zoom level change. That got me to do some useful refactoring so nice catch!

For everyone else; the implementation has gone through a complete re-write based on patterns I observed from both Niri and cosmic-comp, though end user experience should not change much.
It also comes with working bind actions now.

The current interface:

zoom {
   movement-mode "cursor-follow|on-edge|centered"
   increment-type "linear|exponential"
}
cursor {
   scale-with-zoom
}
binds {
    Mod+Alt+Equal { set-zoom-level "+0.1"; }
    Mod+Alt+Minus { set-zoom-level "-0.1"; }
    Mod+Alt+WheelScrollUp   { set-zoom-level "+0.1"; }
    Mod+Alt+WheelScrollDown { set-zoom-level "-0.1"; }
    Mod+Z { set-zoom-level "1.0"; }
    Mod+Shift+Z { toggle-zoom-lock; }
 }

niri msg action set-zoom-level (+1.0|-1.0|1.0) "output_name"
niri msg action toggle-zoom-lock "output_name"
niri msg zoom-state

I removed a couple of options and actions, as well as the new event. Too much configuration that I feel is rarely messed with, and you can always query the zoom-state so the event felt redundant.

I also implemented dynamic sensitivity based on zoom level. Or at least tried to, I don't know if I did it right, since I couldn't feel any difference.

[zgibberish]

TYSM, this is awesome work!! I haven't tested all the features yet, but I love the current implementation

[Axlefublr]

Omg :DDD the new changes are fantastic!! You even added exponential incrementing? One one hand I think I personally want it, on the other I'm not sure if it needs to be in core. But I feel it is such a common want that yeah, probably it's okay for it to be in core.

OMG!!! DYNAMIC SENSITIVITY!!! I'm so happy 🥹 updating right now to test all the new changes!

[zgibberish]

I just tried the exponential zooming option, it works very nicely, I don't need my script anymore, using the built in actions is faster than my script actually :O

[garfunkel]

This works so well it almost makes me cry. I think the new API is excellent and it also means no need for a separate wrapper script here either.

The exponential mode is pure 😙🤌. Fantastic work.

[Atan-D-RP4]

Don't get too excited yet.

The pick-color action is weird right now, and the screenshot UI is not something I'm currently co-operating with.

Also, this deserves pinch-in/out gestures and I intend to deliver.

I'm trying to see what integrating with animations system will yield for me currently.

[Sempyos]

I will ask, don't feel you must, but has touch support been considered..?

[Atan-D-RP4]

I will ask, don't feel you must, but has touch support been considered..?

I'm the author of the touch-gesture PR, so yes. I mentioned that above didn't I?

Oh, I see that I didn't.

But still, that's going to take a while since Niri itself does not fully support touch gestures yet.

[Atan-D-RP4]

@Axlefublr and @zgibberish
I've managed to resolve all of the issues you've mentioned except the pick-color action one.
Enjoy! Feedback is, as always, welcome and much appreciated!

[zgibberish]

@Axlefublr and @zgibberish I've managed to resolve all of the issues you've mentioned except the pick-color action one. Enjoy! Feedback is, as always, welcome and much appreciated!

@Atan-D-RP4 Thank you! The mouse jittering effect is now gone, feels much nicer :p

The cursor pushing on edges with the on-edge movement type issue, is now also gone for me. But when adjusting zoom level with on-edge mode, the viewport isn't constrained to the cursor's position, when zooming further in, it tends to move to the bottom right corner of my screen. The viewport loses the cursor and movement is weird, it returns to normal after I move my cursor towards the zoomed viewport so it enters the screen again.

[Atan-D-RP4]

Yeah the zooming in with on-edge movement is a bit weird still. Haven't gotten to that yet.

As I mentioned, the movement modes skill issued me pretty hard. I went through multiple implementations nnd I'm still not happy with the code I ended up with, but it works for now.

[SergeGris]

Some thoughts

Sooo, ahh... Idk, toggle-zoom as it was before would be bad UX, but I want in future have something to toggle zoom level between 1 and some value. What about toggle-zoom-level 1 2 3 that iterates between values and behaves like:

// action skeleton implementation
fn toogle_zoom_level(levels: &[u32]) {
    let mut level = get_zoom_level();
    let next = levels.iter()
        .filter(|&&x| x > level)
        .next();

     return if let next = Some(next) { next } else { levels[0] }; // or: else { 1 }; or: else { get_fallback_zoom }
}

With animations I suppose it will work veeery nice and beauty

I've added in my config this lines and have veeery nice UX for now with mouse that have additional two buttons under my thumb:

    Mod+MouseForward { spawn-sh "niri msg action set-zoom-level +0.5"; }
    Mod+MouseBack { spawn-sh "niri msg action set-zoom-level -0.5"; }

...gpu smoothing/antialiasing (optional?)?...

Bug:
On such config:

zoom {
   movement-mode "cursor-follow"
   increment-type "exponential"
}
cursor {
   scale-with-zoom
}

1. Zoom
2. Start selecting text
3. Text started to be selected from shifted position

P.S.: Bug:)

1. Have at least 2 monitors
2. Zoom one of them
3. focus-monitor-{down,up,left,right}
4. You may have cursor appearing on both monitor, on initial it changes pixmap (pointer, selecting cursor etc), but does not move and duplicate real cursor.

P.P.S.: Despite above issues and so on, for now as for me this feature works as I wanted and I am so happy and satisfied that someone implemented it and you did it very good as for me!

[Axlefublr]

I think toggle-zoom-level is a niche enough want that it's an eh decision to put it into core.
A user can easily implement it in a script.

You could instead just do this :3
No need for the shell overhead.

Mod+MouseForward { set-zoom-level "+0.5"; }
Mod+MouseBack { set-zoom-level "-0.5"; }

Agreed! This feature finally “completes” wayland for me. It was the last unsolved usecase of mine.

[Atan-D-RP4]

You think so? With animations (If I can get them right) having this:

zoom {
   preset-zoom-levels 1.0 1.5 2.5 3.5
}

With a niri msg action switch-preset-zoom-level would look and feel really good. In my head at least.

You think this falls under the config being 'too nice' bracket?

[Axlefublr]

Well, I assume that set-zoom-level would play an animation already, and with that in mind yeah, definitely “too nice”.
Every change that we make, once it gets merged, will need to be maintained forever by yalter. And so it's a good idea to be conservative about features that are fully reproducible outside of core.

[Atan-D-RP4]

Yeah you've got me on that.

[SergeGris]

I think toggle-zoom-level is a niche enough want that it's an eh decision to put it into core.
A user can easily implement it in a script.

Yeah, that's possible, but such api seems consistent with niri's preset-column-widths. Anyway, it's just a thought :)

You could instead just do this :3
No need for the shell overhead.

Mod+MouseForward { set-zoom-level "+0.5"; }
Mod+MouseBack { set-zoom-level "-0.5"; }

Oh, i missed it, I've had some troubles with config also because of rebuilding different branches of niri, so i forgot to clean it

[Atan-D-RP4]

A couple more changes were pushed. Now everything should be fixed. Pretty sure. I hope. About 80% certain.
Break it in guys.

[zgibberish]

On a7103d7, my system often freezes when using Steam, can anyone reproduce this?

[Atan-D-RP4]

I tested cb56207, the issue still remains

On Steam? Because Libreoffice does work on my machine.

[Atan-D-RP4]

Ok, so I tested with Steam as well and figured out what's causing the problem.

Pushed a fix. Please check again if it still breaks. Pretty sure it'll work though.

[zgibberish]

I'm testing the latest patch, it's been stable so far. TYSM ❤️

[miku4k]

@Atan-D-RP4 it seems this bug is back again.

[Atan-D-RP4]

@miku4k Can't replicate it. I'm testing on my latest commit, so this one 0f49be2d. Both Only Office and Steam work perfectly fine for me. Any instructions to reproduce or screen capture of the issue would be appreciated.

[Atan-D-RP4]

I fixed a regression which re-introduced jitter on the cursor when moving the zoomed viewport in the on-edge movement mode. I did not test for that when I patched the issue with Steam and LibreOffice. Sorry about that!

I also cherry-picked some of the refactoring commits from the Blur PR.
Hopefully I've not broken anything now.

But with this, I consider this PR pretty much stable and finished from a feature and integration perspective. If anyone notices any performance issues or has suggestions for profiling it, please let me know.

As always, thank you for testing out my work. Hope you enjoy the feature.

[Axlefublr]

thanks! but in some time, those hashes will likely get invalidated, becoming unhelpful to the next person reading this thread that wants to get blur + zoom. my (expected) workflow is to first squash all commits of the blur branch into one, and cherry pick it to my fork branch. then do the same with the zoom pr. so, making blur pr the basis so to speak. so maybe that's viable? :>

[Axlefublr]

for context, this is more or less how I manage all of my forks. by squashing all commits of a pr into one, you only need to handle the merge conflicts of the final state, rather than solving conflicts that already got solved by the pr author a bit of time later.

[Atan-D-RP4]

thanks! but in some time, those hashes will likely get invalidated, becoming unhelpful to the next person reading this thread that wants to get blur + zoom.

Yeah, the list of hashes is basically just commits I haven't cherry-picked onto the zoom branch. You can probably get away with just cherry-picking everything.

my (expected) workflow is to first squash all commits of the blur branch into one, and cherry pick it to my fork branch. then do the same with the zoom pr. so, making blur pr the basis so to speak. so maybe that's viable? :>

It definitely is. I ran the previous cherry-pick I mentioned, and only had to resolve some minor conflicts such as not mangling function signatures and stuff, and also updating the RenderElement::<GlesRenderer>::draw function signature to properly work with the updated Smithay. Should be no trouble, relatively speaking.

[Atan-D-RP4]

What I should do, is to soft reset to my entire tree to main, and then do commit a cleaner history. No one needs to sift through over 75 commits for one feature.

[Axlefublr]

agreed! that would be best 😌

[zgibberish]

Has anyone noticed this issue where the mouse cursor jumps when pushed against the bottom & right edges?

2026-04-01.13-50-44.niri.magnifier.cursor.jumping.mp4

But it doesn't show in screen recordings (???)

[YaLTeR]

It's a pre-existing niri issue and there's no good/satisfying/easy fix for it. It has to do with exclusive check on whether a coordinate is inside an output rectangle (< width, < height) vs. coordinate clamping having to be inclusive.

[Atan-D-RP4]

I'd like to ask if people are happy with the texture filters and how they are currently being applied.

Especially with the Niri drawn UI overlays like the help panels, exit confirm dialog, error notification, and mru window ui. These are never rendered with zoom applied but due to how I apply the texture scaling will still receive texture filter scaling when zoomed in.

[bczhc]

So cool.! Especially this works with screenshot-ui. This way I can use screenshot ui to 'freeze' the screen and use the magnifier to do some pixel level inspection for the video buffer.

There's one small keybind issue: I'm using the example config

    Mod+Alt+WheelScrollUp   { set-zoom-level "+0.3"; }
    Mod+Alt+WheelScrollDown { set-zoom-level "-0.3"; }
    Mod+Z { set-zoom-level "1.0"; }
    Mod+Shift+Z { toggle-zoom-lock; } // locks focal center, will also make it lock level

and Mod+Z and Mod+Shift+Z don't work when screenshot-ui is present.

[Atan-D-RP4]

Good catch. I've mainly used the gestures with this since I implemented them, so didn't check/test actions with the screenshot UI.
Patched!

[zgibberish]

If I screenshot a region while zoomed in, the portion that goes off-screen is blank on the result image, is there anything that can be done to fix this?

To better visualize what I mean:

• Yellow: highlighted region (captured image size)
• Bright: Magnified view (whats visible in captured image)

[Atan-D-RP4]

Damn. This didn't happen before blur merged right? I put a lot of work into ensuring what's being displayed, in the capture region, and what's finally captured stay consistent. Probably missed something in the rebase. Let me get back to you in a bit.

[bczhc]

Just tested; this issue exists before the rebase (@ 0db16fa)

[Atan-D-RP4]

Should be now fixed on the latest commit.

[zgibberish]

Just tested, screenshot is working well now, thank you <3

[garfunkel]

One thing I notice is that when you are zoomed in, the cursor movement is slowed down, is there any way to configure it so that zoom level doesn't affect how fast the cursor moves around the desktop?

[Atan-D-RP4]

I'm surprised to hear you say that. I think it was Axel who said that the dynamic slowdown based on zoom level was deeply expected behavior and since implementing it, I've come to agree with him.

Before I go and introduce a config option for that, I'd like to ask how much of a deal breaker it is for you? Since I don't want to add too much config.

I'm already ripping out all animation config for zoom, since some sane defaults for those should serve everyone fine enough.

[garfunkel]

For me it is a bit - reason I didn't notice really until now is that I've done most of my testing with the build as a window inside the Gnome compositor, rather than as a session, and when you zoom in when operated like that it actually doesn't slow down the motion. I only noticed when starting the build recently as a dedicated session.

The slowing of the motion speed is kinda weird to me because your muscle memory of how much mouse movement is required to get your cursor from one point on the screen to another gets very ingrained. When you zoom in and the mouse slows down, you get a different result to what you expect and it throws you off. You physically move the mouse the same amount on the pad and you get 1/2 the result, or 1/4 the result.

[Atan-D-RP4]

When you zoom in and the mouse slows down, you get a different result to what you expect and it throws you off. You physically move the mouse the same amount on the pad and you get 1/2 the result, or 1/4 the result.

Isn't that exactly why you would want slowdown? Since the contents are enlarged, if no slowdown was there, you'd cover the same length of the physical screen but much more of the content in a single motion. I think the latter is more... important to consider.

But I can also understand where you're coming from. Try it out some more as session. If you still want it, I'll add in a toggle or value field for it.

[Axlefublr]

I guess there's always a Usecase™ Man™ just how I anticipated!

[zgibberish]

Can you update the docs for config options on the PR? I'm trying the latest commits (d72d94c) but the options I've used before are now invalid

 > niri validate
Error:   × error loading config
  ├─▶ error parsing
  ╰─▶ error parsing KDL

Error:   × failed to parse included config
    ╭─[config.kdl:11:1]
 11 │ include "rules-window.kdl"
 12 │ include "zoom.kdl"
    · ───┬───
    ·    ╰── node starts here
 13 │ 
    ╰────
Error:   × error parsing KDL

Error:   × unexpected node `zoom-focal-pan`
    ╭─[zoom.kdl:12:1]
 12 │ animations {
 13 │     zoom-focal-pan      { spring damping-ratio=1.0 stiffness=2500 epsilon=0.0001; }
    ·     ────────────────────────────────────────┬───────────────────────────────────────
    ·                                             ╰── unexpected node
 14 │     zoom-level-change   { spring damping-ratio=1.0 stiffness=2500 epsilon=0.0001; }
 15 │ }
    ╰────
Error:   × unexpected node `zoom-level-change`
    ╭─[zoom.kdl:13:1]
 13 │     zoom-focal-pan      { spring damping-ratio=1.0 stiffness=2500 epsilon=0.0001; }
 14 │     zoom-level-change   { spring damping-ratio=1.0 stiffness=2500 epsilon=0.0001; }
    ·     ────────────────────────────────────────┬───────────────────────────────────────
    ·                                             ╰── unexpected node
 15 │ }
 16 │ 
    ╰────

[Axlefublr]

ah well to elaborate: if you zoom to look at not the middle of the screen, each zoom is “jumpy” in terms of the animation, because there isn't enough space to keep your cursor in the middle of the screen. which is expected behavior, I just dislike it, and ended up disabling animations for zoom altogether lol

[Atan-D-RP4]

ah well to elaborate: if you zoom to look at not the middle of the screen, each zoom is “jumpy” in terms of the animation, because there isn't enough space to keep your cursor in the middle of the screen. which is expected behavior, I just dislike it, and ended up disabling animations for zoom altogether lol

Are you sure that's not just because you're using spring animations? I've not noticed jumpiness when changing zoom levels.

I've not actually removed the animations with this change, only their user facing config. And then hardcoded a default. I forgot what curve I used, just that it felt smooth and natural.

And niw I'm realizing we need another way to disable the animations. Damn it.

[Axlefublr]

yeah I just tried the new default and yep I still hate it. haven't programmed much last two months, so I think I've gotten stupider, and my best solution for removing animations (in the source code) is setting the duration to 1 — which does an annoying visual correcting step every so often, if you press your hotkey for changing the zoom level frequently.
Setting it to 0 doesn't work to my surprise, setting the off property to true doesn't work; I tried removing the …Animation types from src/layout/mod.rs + everything that came from them, but that also made changing the zoom level do nothing.

By jumpiness I don't mean the spring type of jumpiness.
Imagine a square. You place a point in the corner of the square.
You zoom in to the point. Because it's in the corner of the square, you necessarily cannot put that point into the middle of the screen. You could if you added padding around the square, but since you don't have it, the transition will necessarily never be smooth.

I would like there to be padding but that's probably an annoying amount of code so I'm not suggesting that lol

[Atan-D-RP4]

By point or square, you mean the pixel, right?

Jumpiness when you move the cursor at high zoom level, almost like jitter? The cursor going wobbly during motion?

If so, then that's not the animations, and something I've been working on fixing (I thought I already did 😭).

[Axlefublr]

nah, square is the screen, point is the mouse cursor. I'm not sure why I decided to give an analogy in the first place hahaha

nope! jumpiness in the animation of when you change your zoom level

but it sounds like the jitter you're mentioning is the “visual correcting step” I talked about

[Atan-D-RP4]

How many people really want the scale-with-zoom setting, and how much do they want it? Is it fine if we just pick one of either scaling the cursor or not in a hard-coded fashion?
I ask, because it would clean up an annoying amount of code and simplify a bunch things and I've not seen any other compositors offer this setting.

[Axlefublr]

same, I want it to be disableable if nothing else. at the same time I do believe it's a worthwhile option to have for accessibility. hope I've developed trustworthiness after all the “nah, this we don't need” I've expressed throughout the development process hahaha

[Atan-D-RP4]

i really want it. i already lose it sometimes when not zoomed in, and it confuses my visual processing a lot if something doesnt scale.

This one could be mitigated by the PR that implements the KDE style cursor find (I can't find it right now).

[Atan-D-RP4]

same, I want it to be disableable if nothing else. at the same time I do believe it's a worthwhile option to have for accessibility. hope I've developed trustworthiness after all the “nah, this we don't need” I've expressed throughout the development process hahaha

Eh, I've always taken what you said as valid pushback. I've not changed the interface much in a while, and I think that's a testament to how much bikeshedding we did.

I'll trust @miku4k or @zgibberish over you any day though. (kidding, btw)

The only thing I'm still iffy on, is my choice to rip out the zoom animations config.

[zgibberish]

i really want it. i already lose it sometimes when not zoomed in, and it confuses my visual processing a lot if something doesnt scale.

This one could be mitigated by the PR that implements the KDE style cursor find (I can't find it right now).

I believe you're thinking of this PR?
#2797

I don't think it would work well tho, wouldn't shaking your cursor while zoomed in shake your whole viewport too?

[Atan-D-RP4]

I believe you're thinking of this PR?
#2797

That's the one.

I don't think it would work well tho, wouldn't shaking your cursor while zoomed in shake your whole viewport too?

For the cursor-followed and centered movement modes. But it'll be great with the on-edge mode.

[zgibberish]

Can we have screen zoom related actions be allowed when screen is locked? Since the zoom gesture works when locked, it would make sense that the actions triggered with keybinds also work there.

[Atan-D-RP4]

I mean, they are just actions. You can use allow-when-locked=true setting for them in the kdl when you bind them.

[zgibberish]

allow-when-locked is only allowed for spawn actions.

[miku4k]

I just noticed that my non-primary monitor doesn't render anything but the cursor and most builtin compositor ui when zoomed in. screenshots and window capture work flawlessly, but screen capture is also affected (presumably because that doesnt rerender anything). it doesn't happen when its the only active output, and my primary monitor works fine in any case.

2026-05-23.15-49-26.mp4

[Axlefublr]

incidentally, oh my god I love that wallpaper, please send it!!

[miku4k]

its from the old slimerancher website

[Atan-D-RP4]

I pushed a bunch of commits, one of which should fix this.
Try it out and check if it does.

[zgibberish]

I was testing the latest commit (at the time was c9bab5b)

and was getting many random freezes while zooming, it was like that time with Steam, but now in Zen browser, not sure if it's exclusively in Zen, I haven't done much extensive testing. The screen would just freeze, all input stops working, but I could still get notifications, and audio still plays.

Right now I downgraded to d72d94c, no issues there.

[niv-l]

Getting similar issues here

[Atan-D-RP4]

I can run onlyoffice via xwayland just fine. Steam worked fine last I checked, will check again tomorrow. Picard did not give me any issues. Any other Xwayland clients I should test against? Cause I can't reproduce this. I've been running the latest commit the whole week now and had zero issues.

[zgibberish]

I'll try to test more tomorrow when I have time

For more context, I've had my output at 1.25x scale, idk if that is any help rn

[Atan-D-RP4]

I got a comment on the PR thread that running discord and only-office with the PR compiled crashed Niri for them. But I simply can't replicate it.
Steam, OBS, Discord, OnlyOffice, Picard, EasyEffects, they all run perfectly fine for me.

I tested them all with this monitor config:

output "eDPI-1" {
    // position x=0 y=1280
    position x=1280 y=0 // Tried both
    scale 1.67
    transform "normal"
    mode "1920x1080@60.000" // preferred for my monitor
}

[Atan-D-RP4]

What movement-mode are you using for testing this freeze? Does it happen in all movement modes?

[0xAdk]

Are there any plans to add shaders like KDE's zoom's pixel shader or the new with plasma 6.7 upscaling shader?

[Uzlkav]

I'm not sure either of those really count as shaders, but you can get sharpness at high zoom levels with the zoom-filter-threshold option - look at the docs in files changed for more info

[Atan-D-RP4]

After doing a bit of digging into this, I don't we can provide this yet. Not without resolving this #913, or at least some subset of it.

Kwin is applying full screen post processing shader. Niri currently does not have long-running shaders for both windows and fullscreens/outputs. And as discussed in the linked issue, implementing them is non-trivial since they interact with damage-tracking.

I wanted to take a shot at it, but YaLTeR said he wanted to do it himself. Maybe I will try though.

[0xAdk]

I'm not sure either of those really count as shaders, but you can get sharpness at high zoom levels with the zoom-filter-threshold option - look at the docs in files changed for more info

I only called them shaders since that was how they were implemented in kde. "effect" probably would be the better generic name.

[Axlefublr]

Ever since zoom animations couldn't be disabled, I've been experiencing an issue I describe fully in my blog post, in this section.
The core of the problem is that when you press the incremental zoom hotkey of yours, you multiply your current zoom level, instead of the zoom level you're in the animation to get to.
This leads to inconsistent zoom levels.

I mentioned it half-handedly in the niri discord; yalter expressed “this is definitely not how it should work”

[Atan-D-RP4]

So I went through that section of your post (need to go through it entirely again, cause advanced Kanata user, hello!), and I need to think about it.

Is rounding the target zoom when calling the set-zoom-level action good enough or a band-aid fix?
The zoom animation target should be a simple fix. My workflow for using zoom doesn't involve hotkeys (I love my gestures) so never ran into this UX issue.

[Axlefublr]

Omg Atan, are you also an advanced kanata user? :D yay!
I have two more blog posts about kanata actually! One is about composite layers (unfortunately very advanced 😭) and the other one about my every row mod setup

Nah, it is definitely a bandaid. I can definitely see some spacebar heaters rely on being able to set a non-integer zoom value, for some niche but significant reason.
Plus it doesn't address the issue fully: with hotkeys, the expectation is that an X amount of presses will always result in zoom level Y. Currently, if you make the X amount of presses faster, your zoom level will end up less than Y. I don't think rounding would solve this problem consistently, if at all.
The multiplication happening on the target zoom level rather than on the current one should be fantastic. Maybe something like “on pressing the hotkey, change (multiply) the target and restart the animation, now targetting the new target”?

[Atan-D-RP4]

Not so advanced of a kanata user. Just a couple of layers, one for default keys, one for homerow mods, one for number row mods, custom global abbreviations, caps-esc, an auto-clicker, and a key chord for tab that I can trigger with my right hand.
Most of it inspired from the maintainers own config shown as example. I've been trying to make the abbreviations better but failed.

The fix for quick pressing hotkeys giving you not the expected zoom level is an easy fix. When creating the zoom-level animation, just check if one is already running and if so use it's target level instead of the current.

[Atan-D-RP4]

Also:

From no zoom (1), I start increasing: 1 → 2 → 4 → 8 > → 16
16 is higher than 10, so the zoom is capped at 10.

Cool, now let's zoom back out.
10 → 5 → 2.5
Two point five.

there's not much that can be done about this, I think, other just using linear zoom increment.

That the display looks cummed-on, though, when the zoom level is non-integral is a separate issue that needs investigation.

[Axlefublr]

yeah, that was mostly just me explaining why I set my max zoom so infinitely high

:D lmaooooo