At the moment, the Aurorae decoration engine may cause frame drops in some cases. It's worth looking into passing the opengl texture where the decoration is rendered directly to the opengl scene. Also, Aurorae decoration engine may hit the slow path in FrameSvgItem.
Created attachment 134896 [details] hotspot
Created attachment 134897 [details] ftrace
Might tackling this also fix (if only due to the reformulation) bug #425864, invisible aurorae-based windecos when used with libglvnd? (I'm on wayland by default now, and actually patch the oxygen windeco so the titlebar's shrinkable enough that I don't any longer need the aurorae-based windeco I used to use to get short titlebars, different-bug #425874, but it'd still be nice to have the -864 X-only bug fixed. I'm CCing so I can track and test in X when the code for this hits git.)
From the hotspot it appears the FrameSVGItem is the worst offender of those two issues. Copying some context from the other report. * FrameSVGItem is a 9-tile system * For each new size we can stretch (fastest), tile (fast) or re-render the SVG into a new texture (suuuuuuuuuper slow), based on hints * The default (for compatibility from Plasma 4 times) is to re-render * We are rendering /the entire/ frame behind the window. This is mostly the centre tile Setting + tileCenter = true; in framesvgitem.cpp:572 I don't think would break many themes.
(In reply to David Edmundson from comment #4) > From the hotspot it appears the FrameSVGItem is the worst offender of those > two issues. > > Copying some context from the other report. > > * FrameSVGItem is a 9-tile system > > * For each new size we can stretch (fastest), tile (fast) or re-render the > SVG into a new texture (suuuuuuuuuper slow), based on hints > > * The default (for compatibility from Plasma 4 times) is to re-render > > * We are rendering /the entire/ frame behind the window. This is mostly the > centre tile > > > Setting > + tileCenter = true; > in framesvgitem.cpp:572 > > I don't think would break many themes. With most of the themes I could test, it looks to work okay. It's also waay faster.
I am on Plasma 5.26.5, and aurorae decorations are still much slower than the default Breeze Decoration. Resizing and moving windows feels much less fluid with aurorae.
Still an issue on 5.27.8, resizing windows is really choppy. I'm using https://github.com/efskap/XBoomer
With the first qt6-based plasma6 (I'm assuming they're calling it that) release due in February, betas from December and possibly even an alpha in November (unknown whether it's still on for then or early/late Nov but that's only ~4-6 weeks out!!), there's very little chance a fix will hit qt5-based plasma5, particularly since the center-tile-focused efficiency fix discussed in comment #4 and comment #5 may well break /some/ existing third-party aurorae-based theme (even if as expected it's fine for ninety-some percent), and as an at least theoretically breaking change, at this point it just doesn't make sense to do it in 5. But here's hoping they take the opportunity to do it for 6, since this would be the time to do any breaking changes there and the efficiency boost should be well worth it. Maybe this new bug activity will get them on it (if they're not already doing it that way in 6).