Rendering screenshots above output resolution

[xevrion]

I have been building a screenshot tool that captures at higher-than-display resolution, the way a game's photo mode or the Minecraft Fabrishot mod does: render the scene at N times the size so text and vector UI are re-rendered at that density, rather than upscaling a display-resolution capture.

While looking into how to do this on niri I noticed that Niri::screenshot is already almost there. It renders into an offscreen texture and takes both the size and the scale as arguments:

let size = output.current_mode().unwrap().size;
let scale = Scale::from(output.current_scale().fractional_scale());
let pixels = render_to_vec(renderer, size, scale, Transform::Normal, Fourcc::Abgr8888, elements)?;

Multiplying both by a factor renders the same scene into a larger texture. I tried it locally against 26.04 as a rough experiment:

let ss = /* requested factor */;
let size = Size::from(((size.w as f64 * ss) as i32, (size.h as f64 * ss) as i32));
let scale = Scale::from((scale.x * ss, scale.y * ss));

A nested instance with a 1262x1386 output then produced a 5048x5544 screenshot, with no modeset and nothing about the output changed.

The result is a real re-render rather than interpolation. Downscaling that 4x capture back to native and comparing it against a plain capture of the same scene gives an RMSE around 0.12, where doing the same with grim -s 4 on a comparable scene gives roughly 0.02, since -s is a pixman resample of the already-captured buffer. So there is detail present that does not exist in the output-sized buffer, and glyph edges are visibly cleaner at 1:1.

Before I take this any further I wanted to ask whether it is something niri would want, and in what form:

1. Is rendering a screenshot above output resolution a direction you would consider at all? I could not find an existing issue or discussion asking for it, so I may be the only person who wants this.

2. If so, would it belong in the screenshot path, or is this better left to the virtual output work in Add virtual output support #3800? With virtual outputs I could create an oversized output, move a workspace onto it and capture that, which is more flexible but also more moving parts for the simple "capture what is on screen, but larger" case.

3. If the screenshot path is reasonable, how should the factor be passed? A field on the ScreenshotScreen IPC action seems most natural, though that touches niri-ipc and niri-config, and I would rather not guess at the shape.

Happy to do the work and testing either way, and equally happy to hear that this is out of scope. I did not want to open a pull request for a feature nobody asked for, especially with #3800 already active in the same area.

One unrelated note in case it is useful: while scripting this I ran into #2664, where niri msg action screenshot-screen returns before the file is written. It is straightforward to work around by polling for the file, just confirming it still reproduces on 26.04.

[xevrion]

Correction and a working follow-up. The experiment in my original post overclaims. Multiplying only the screenshot render's size and scale does produce an NxN image with no modeset, but the client content in it is not re-rendered: the clients were never asked to change scale, so their buffers stay at 1x and the render upscales them. Measured with a matched-content sharpness metric, client text in those captures is exactly as soft as a Lanczos upscale of a normal screenshot. What fooled my original RMSE comparison was compositor-drawn content (borders, backgrounds), which genuinely does render crisply at any scale.

The version that actually works adds one step: before rendering, send every surface on the output a boosted preferred scale (wp_fractional_scale_v1 plus integer preferred_buffer_scale), give clients a settle delay on an event-loop timer to re-render and commit, render the supersampled screenshot, then restore the scales. Client logical sizes never change, so the visible screen does not move during this (measured 1.5% RMSE against a before capture, below normal content churn), and there is still no modeset.

Numbers from nautilus (GTK4) on a nested 26.04 build, using edge-to-contrast ratio on identical header text, where fully crisp native text scores 0.547 and a Lanczos upscale scores 0.192: factor 2 scores 0.353 (genuine re-rendered detail), factor 4 scores 0.215 (partial, diminishing). Client cooperation decides the gain: GTK4 is well behaved at 2x, kitty misplaced its content at 4x with a short settle, and clients that ignore the hints degrade to upscale quality rather than below it.

So the shape of the feature is less "multiply two numbers" and more "briefly re-negotiate surface scales around an offscreen render", roughly 120 lines. That overlaps conceptually with what virtual outputs in #3800 would enable. Happy to share the diff or turn it into a PR if either direction is wanted.

[YaLTeR]

You can't really make this feature not jank. I suggest scripting with IPC instead.

If you don't need the full desktop, you can already resize windows to arbitrary sizes (bigger than output) and set arbitrary output scales, then screenshot-window them.

[xevrion]

Thanks, that works nicely. Implemented exactly as IPC scripting: float the window, pin its logical size, raise the output scale, screenshot-window, restore. One detail for anyone following: the resize has to land before the scale change, and only floating windows keep their logical size across it. Genuinely re-rendered 4x captures on stock 26.04. Agreed the full-desktop variant can't be made non-janky from IPC; the per-surface scale experiment stays out of tree.