KDE-Rounded-Corners: a KWin effect that rounds window corners without the performance cost

What it does, and the two upstream projects it started from

KDE-Rounded-Corners is a KWin effect that rounds the corners of your windows and adds an outline around them, and the README's first claim is that it does so without much affecting the performance of the KDE Plasma desktop. Two links are given for that claim, a pull request numbered 49 and an issue numbered 50, which is the sort of evidence trail a performance claim should come with.

The lineage is unusually well documented for a small effect plugin. The effect started as a fork of shapecorners, with some additional contributions in Alex47's project, and was then optimized and reimplemented using shaders with influences from the invert effect in the KWin source tree.

That progression is the interesting engineering story. A fork of an existing effect inherits the original's approach, which for window decoration means manipulating window shapes rather than drawing them. The rewrite to shaders is what moved the cost onto the GPU, where a corner rounding is a fragment operation rather than a CPU side geometry change, and the influence from the invert effect matters because that is a KWin effect that already solved the problem of drawing a screen-space effect across the whole output without per window overhead.

The effect targets the window manager, not the desktop environment as a whole, and the topic tags name the mechanism precisely, kwin-effect and rounded-corners. The primary language is C++, the licence is GPL-3.0, and the recent releases are v0.10.0 on 2026-08-23, v0.9.0 on 2026-06-06 and v0.8.7 on 2026-03-18. The last push was on 2026-10-18, and the repository is not archived.

The supported matrix, and where the gaps are

The README states the effect is maintained on KDE Plasma desktop versions 5.27 to 6.7+ in various Linux distros, and the badges in the tested configurations section spell out what that means in practice, one row per distribution.

Both Wayland and X11 are supported, which is worth noting because a lot of Plasma effect work in recent years has been X11 only or has had a Wayland story that lagged. The effect works under both session types.

Kubuntu 22.04 Jammy is marked as not supported, and it is the one row with an explicit red not supported badge. The same row carries a Plasma 5.24 badge, so the reason is the Plasma version rather than the distribution itself. The supported Plasma range starting at 5.27 is what excludes it, and that is a meaningful constraint because 22.04 shipped with 5.24 and its long term support status means a lot of people are still on it.

The rest of the matrix is a rolling list of current distributions, each with a CI workflow badge showing the build status, a Plasma version badge and a packaging route. Kubuntu 22.04 plus Backports is on Plasma 5.27, Kubuntu 24.04 Noble is on Plasma 5.27, and Kubuntu 26.04 is on Plasma 6.5. Debian 12 Bookworm is on Plasma 5.27, Debian 13 Trixie is on Plasma 6.3, and Debian Sid, the unstable branch, is on Plasma 6.7. openSUSE Leap 16 is on Plasma 6.4, openSUSE Tumbleweed is on Plasma 6.7, and Fedora 44 is on the rolling edge.

Reading the Plasma column across the rows shows the shape of the support. Distributions on older LTS releases sit at the floor of 5.27, and the current rolling releases are on 6.3 through 6.7, with the README describing the range as 5.27 to 6.7 and above.

So there are two separate questions to ask. Is your Plasma version inside the range, and is there a build for your distribution. The second is nearly always answered, since there is a CI workflow per distribution, but the first is the one that actually rules people out.

The upstream projects it grew out of, and the shader rewrite

The lineage of this effect is unusual enough to be worth spelling out, because it explains both what the project does and why it is written the way it is.

It started as a fork of shapecorners, a project that lives on SourceForge, and then picked up additional contributions from Alex47's project of the same name. Those are both pre-KDE-rounding approaches, and they share the same basic technique: they change the shape of the window itself, by masking or clipping the window's outline, so the corners become transparent.

That technique has an obvious cost. Every time the window is resized, moved or redrawn, the geometry has to be recomputed and a shaped region applied, and on a compositor that is work happening on the CPU for every frame the window changes. The README says the effect was then optimized and reimplemented using shaders, with influences from the invert effect in the KWin source tree.

The invert effect is the clue to what the rewrite does. Invert is a KWin effect that colours the screen, and it does so without touching individual windows, by working on the composited output. A shader based rounding follows the same idea: rather than shaping each window, the fragment shader can decide, per pixel, whether that pixel is inside the rounded corner region of the window it belongs to, and discard or tint it accordingly.

That moves the work from the CPU to the GPU and, more importantly, makes it proportional to the pixels actually affected rather than to the number of windows. The corners are a small fraction of any window, so the shader only does meaningful work near the edges.

The performance claim in the first paragraph is therefore a structural claim rather than a tuning claim. The linked pull request and issue are where that argument is made, and for anyone who wants to know whether the effect is expensive on their machine, those are the two documents to read, because they will tell you what was measured and on what.

The reimplementation also explains the version range. A shader based KWin effect depends on the shader API and the effect interfaces of the Plasma version it targets, so it needs rebuilding when those change, and the 5.27 to 6.7 range in the README is the range over which the current implementation has been kept working.

Where the packages come from: PPA, COPR, SourceForge and the build directories

The packaging routes differ by distribution family, and each badge points at a specific artefact, so it is worth knowing which one belongs to which.

For Ubuntu and its derivatives there is a Launchpad PPA per Kubuntu release, with the PPA badges linked from the 22.04 plus Backports, 24.04 and 26.04 rows. For openSUSE Leap 16 there is an RPM download from SourceForge, named kwin4_effect_shapecorners_leap16.rpm. For Debian 12 and Debian 13 there are also SourceForge downloads, named kwin4_effect_shapecorners_debian12.deb and kwin4_effect_shapecorners_debian13.deb. The Debian Sid and openSUSE Tumbleweed rows have no download link, because those are rolling branches where you would build from source or take the distribution package.

Fedora is the odd one out, using COPR, the Fedora infrastructure for user-maintained packages, with a Copr build status badge pointing at a package called kwin-effect-roundcorners. So there are three distribution families covered by three different mechanisms, Launchpad for Ubuntu, SourceForge for Debian and openSUSE, and COPR for Fedora.

The SourceForge ones are labelled nightly in their download paths, which tells you the release channel. The Debian and openSUSE packages are nightly builds rather than tagged releases, and the fact that the repository's own releases are v0.8.7, v0.9.0 and v0.10.0 while the distribution packages are nightly builds means the two versioning schemes are independent.

The build infrastructure in the repository backs this up. The top level has a CMakeLists.txt, a cmake/ directory, a po/ directory for translations, a src/ directory, a tools/ directory, and a .copr/ directory which is the COPR packaging configuration. There is also a .clang-format and a .clangd, so the C++ is formatted by a tool and the language server configuration is committed, which is good practice for a project that expects outside contributions.

Two documentation files sit at the top level, ClassDiagram.md and SequenceDiagram.md, and they are the most unusual thing in the repository. A KWin effect plugin is a small C++ library with a QML interface, and writing out a class diagram and a sequence diagram for it is not standard practice. It tells you the project is documented to a level above what a desktop theme tweak usually gets, and it means a developer can understand the structure before reading the source.

The nature of a KWin effect, and what that implies for you

It is worth being explicit about what kind of thing this is, because it determines what installing it involves.

A KWin effect is a plugin loaded by the window manager, running inside KWin's own process. It is not a window decoration theme and not a compositor setting, it is a piece of code with the same kind of access to your display server as KWin itself, sitting in the path of every window that opens, moves and redraws. That is what makes the outline and the corner rounding possible, and it is also why the performance work mattered and why the pull request and issue on performance are linked in the first paragraph.

The cost model follows from that. A shader-based effect does its work on the GPU but still costs something per window per redraw, and the README's claim is a comparative one, that it does so without much affecting performance, with the evidence trail in the linked discussions rather than a benchmark table. That is an honest way to make the claim, and it is also a claim you should evaluate on your own hardware, since a low powered laptop with a large number of windows is a different case from a desktop with two.

The version constraint interacts with this. The effect is tied to specific Plasma versions, which means it is tied to the KWin API of those versions, and a Plasma major upgrade can break it. The Plasma 5 to 6 transition in particular is the kind of change that KWin plugins have to be rebuilt for, and the matrix showing Plasma 5.27 on the older distributions and 6.3 through 6.7 on the newer ones is a picture of exactly that split.

The other consequence of being a window manager plugin is that it is per user and per session, not a system setting. You install it, you enable it in the KWin effects settings, and it applies to your session. Whether it affects all users on a machine is a packaging question, and the Launchpad PPA and COPR packages for whole systems suggest it can be deployed that way.

What this project is not is a general purpose window theming tool. It rounds corners and draws an outline. If you want a different decoration style entirely, a Plasma theme does that, and if you want a different effect such as a desktop cube, that is a different KWin effect. This one is a single, focused, well packaged change to the look of every window, and the fact that it does that one thing across the tested distribution configurations and two display server protocols is the actual achievement.

Editorial conclusion

KDE-Rounded-Corners fits a Plasma user on a supported distribution who wants rounded window corners and an outline and is willing to install a nightly package from a PPA, a COPR or SourceForge, rather than waiting for a distribution to package it. It is the wrong choice on Kubuntu 22.04, which is marked as not supported, on any Plasma older than 5.27, and for anyone who wants a stable release rather than a rolling nightly. Before installing, check that your Plasma version is in the listed range, take the package built for your own distribution rather than a generic one, and read the linked pull request and issue on performance, because the effect runs on every window redraw and that is where the cost lives.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. matinlotfali/KDE-Rounded-Corners on GitHub
4. README
5. Releases