Hi,
in general I am in favor of removing excessive overdraw (cf. [1]),
putting a background rectangle in when we can instead adjust the window
color. In fact, I did that in KClock [2] but had to revert it after
Kirigami introduced the new page transition.
However, I am not sure the added complexity and performance impact,
especially the shader stuff (that won’t work with software renderer) is
justifiable.
Cheers Kai Uwe
[1]
https://doc.qt.io/qt-6/qtquick-visualcanvas-scenegraph-renderer.html#visualizing-overdraw
[2]
https://invent.kde.org/utilities/kclock/-/commit/dcf179fcb6e1daeaa625fee7b213c6289ec17f9e
Am 31.01.26 um 01:21 schrieb Michael Martin Moro:
Hi !
Some time last year, I implemented a very simple QQuickStyle for Oxygen.
However, Kirigami applications wouldn't display the iconic gradient
background, as Kirigami Pages feature their own background. Upon further
inspection, I figured a/the reason why that background was enforced:
StackView transitions between pages required it, as a transparent
background visually breaks the transitions.
I came up with the following patch:
https://invent.kde.org/plaristote/kirigami
First thing it does, is getting rid of the Page's custom background,
which allows the Window's background to be visible (at least when the
Window component is used, which isn't always the case: I believe
systemsettings is an instance of that).
Since that breaks the page transitions, it also uses ShaderEffect on the
Page element, which duplicates the Window's background, as an underlay,
updating the offset as the transition updates, so the background remains
still. The effect gets enabled when the StackView status for the page is
either Activating or Deactivating.
