Background blur is a negotiation between a window and the compositor. Installing a new Mutter build does not make every existing application translucent.
What is in the prerelease series
Mutter’s 51 release notes list ext-background-effect-v1 blur in 51.beta and background-effect policy in 51.rc. They also describe frame-scheduling fixes. These are prerelease changes; that list is not a benchmark or a promise about every distribution’s package.
The Wayland protocol lets a client request a blur region in surface-local coordinates. It is clipped to the surface, takes effect on commit, and follows compositor policy. Capabilities can change while the client runs.
Why the coordinate boundary matters
Our diagram gives a fictional 800 × 500 window a 300 × 180 translucent panel. The application describes the panel relative to its own surface; it does not receive a screenshot of other windows to blur itself. Moving the window changes which background lies underneath while preserving that local region.
Scaling, resizing and moving between monitors make good validation cases. A rectangle that aligns at one scale may reveal a clipped edge at another. This is a proposed visual review, not an observed Mutter defect.
Make text readable when the effect disappears
A useful client must cope with a compositor that does not advertise the effect or stops applying it. An opaque or sufficiently contrasted background is a more robust fallback than text that depends on the desktop wallpaper being dark.
Compare the same scene with and without blur before judging its cost. Keep window size, scale, refresh rate and animation identical, and examine missed presentation deadlines as well as average rendering time. Release-note scheduling improvements and the extra work of a visual effect answer different questions; neither establishes the net performance of a specific laptop.
September 8: update through Mutter 51.rc and explain surface-local blur, compositor policy and fallback without fabricated performance claims.