fix: keep windows sharp when they are scaled down

[rcmz]

Fixes #36 — windows with rounded corners are blurry and washed out in the overview.

That issue is labelled upstream issue, and the underlying bug (gnome-shell#7903) is real and still open. But it turns out the extension can side-step it, so this isn't a fix for the GNOME bug — it's a workaround that stops the extension from tripping over it.

Same window preview in the overview, zoomed 4x — top: extension disabled, middle: current main, bottom: this PR

What actually goes wrong

GNOME paints a window from a half resolution copy of its texture once the window ends up smaller than half size on screen (MetaTextureMipmap — level 0 of that copy is literally width / 2 × height / 2).

The corner rounding shader is a Clutter.OffscreenEffect, so a window that has it is first rendered into an offscreen texture at its full size, and that texture is painted in place of the window. GNOME still makes the half resolution decision from the size the final result lands at, even while it is filling a full size offscreen texture. So the offscreen texture ends up holding a blurry, upscaled copy of the window, and the detail is gone before the texture is ever painted.

That last part is why LinearFilterEffect could only ever help a little: it changed how the result was filtered, but the detail had already been thrown away one step earlier. I measured every filter option on the offscreen texture (NEAREST, LINEAR, both mipmap modes) and all of them stayed 3-8x below the sharpness of a window without the effect.

What this changes

• Turns mipmaps off on the window's texture while the effect is attached (setCreateMipmaps, paired in createEffect / onRemoveEffect), so the offscreen texture gets a faithful copy of the window.
• Adds effect/texture_filters.ts, which picks the filters for the offscreen texture per paint, based on how much it is scaled down: GNOME's own choice at 1:1, LINEAR when scaled down, and LINEAR_MIPMAP_LINEAR below 0.25 — window previews in the workspace switcher are painted at about 4% and turn into speckles otherwise. This is the part GNOME can no longer do for us.
• Removes LinearFilterEffect. It added an extra full size offscreen pass over every window preview, only ever applied to previews of windows that had a shadow, and could not undo the detail that was already lost.

Testing

Tested manually on GNOME 50 (Wayland) at 4K, and measured in a headless GNOME Shell 48.7 session (gnome-shell --headless --virtual-monitor 1920x1080) with six identical terminal windows, comparing against the exact same scene with the extension disabled.

Sharpness is the variance of the Laplacian over the window preview area; diff is the mean absolute pixel difference from the extension-disabled reference, on a 0-255 scale:

	previews	diff	thumbnails	diff
extension disabled (ref)	9162	0.000	495	0.000
current main	1155	7.636	1108	1.179
this PR	9191	0.556	428	0.423

Desktop rendering at 1:1 is unchanged: 97.2% of pixels in the window area are identical with and without the extension, the same as before this change. vfunc_paint_target restores the filter GNOME picked whenever nothing is scaled down, so nothing changes outside the overview.

X11 windows were measured separately, since the effect lives on firstChild there. Comparing each build against the same scene with the extension disabled, using six xterms:

	on main	with this PR
XWayland	20%	99.7%
GNOME X11 session	22%	99.96%

(percentages are preview sharpness as a fraction of the extension-disabled reference in the same session)

Also checked: rounded corners and overview shadows still render, and biome ci . and just build both pass.

Disclosure

Per the PR template: this change is mostly AI-authored (Claude Opus 5, via Claude Code), including the investigation of the root cause. I reviewed it and tested the result on my own machine before opening this PR, and the numbers above come from actual runs, not from the model's description of them. The commit carries a Co-authored-by trailer.

Happy to adjust the 0.25 mipmap threshold, split the commit, or drop the LinearFilterEffect removal into a separate change if you'd prefer.