when some effects like maximize or translucency are
disabled, less repaints happen and especially when
using aurorae it's possible to trigger some repaint bugs:
if you maximize a window then quickly unmaximize it
by dragging the decoration away, sometimes a piece of the
old decoration (seems only the shadow part) remains on screen
this extra addLayerRepaint seems to make the problem
harder to reproduce, even tough sometimes still happens
maximizing and unmaximizing the window many times seems to
leave graphics behind almost never now (unfortunately, almost
so there is still something broken somewhere)
the reason aurorae seems to trigger it a lot, is that a
setShadow happens during the repaint, that is triggered by a timer.
if like in oxygen i do a setshadow only connected to the signal
KDecoration2::DecoratedClient::activeChanged the problem
does not seem to happen, but of course that happens too soon
and the graphics is still wrong.
another possibly related bug, that seems harder to reproduce
is in https://www.youtube.com/watch?v=IfbHVApLbyg&feature=youtu.be&t=79
(moving the window, a piece of shadow stays there)
| No Linters Available |
| No Unit Test Coverage |
| toplevel.cpp | ||
|---|---|---|
| 325 | We do have the repaints already. Check the dirtyRect and the following addLayerRepaint. Instead of adding a new call lets fix it. | |
| toplevel.cpp | ||
|---|---|---|
| 336–337 | About me, rectangle should not be translated to pos, cause it does not contain shadow (who stays not updated) | |
| toplevel.cpp | ||
|---|---|---|
| 325 | isn't dirtyrect only the new decoration geometry, while oldvisiblerect the old before the geometry change? or is dirtyrect supposed to be an union of old and new geometries? | |
| toplevel.cpp | ||
|---|---|---|
| 336–337 | shadow()->shadowRegion().boundingRect() is a rectangle always in relative coorninates from the shadow, ie , always at 0,0 | |
| toplevel.cpp | ||
|---|---|---|
| 325 | you mean something like this? | |
| toplevel.cpp | ||
|---|---|---|
| 325 | yeah, though we kind of already had this. We have the old shadow region in the dirtyRect (line 326) and in line 332 we combine it with the new shadow rect. Your change only results in repainting the complete window and I don't really understand why that is needed. | |
| toplevel.cpp | ||
|---|---|---|
| 325 | aah, right. any idea? | |
| toplevel.cpp | ||
|---|---|---|
| 325 | this is related with https://phabricator.kde.org/D4990 | |
In the video the shadow stays when moving the window. Given that and the knowledge of the distribution in question I doubt it's in any way related to the shadow at all but rather to the used effects. I assume that we have a repaint issue in a completely different area which just doesn't show with the default settings (please observe that translucency effect seems to be disabled). Given that what we need to know is which settings did the distribution change. Back in the days of Netrunner this used to be horrible by mostly delivering a broken (sic!) kwinrc. Netrunner used to ship a manually adjusted kwinrc with all auto detection mechanismns disabled by accident, thus a system could easily create rendering issues just by having the false settings.
So in this case we need to really take a step back and look at the changes the distro did.
For moving windows, to me the culript seems to have the translucency effect while moving windows off
So in this case we need to really take a step back and look at the changes the distro did.
the kwinrc of the (two) distributions in question, are:
https://github.com/maui-common/maui-settings-theming/blob/master/usr/share/default-settings/plasma5-profile/kwinrc
https://github.com/netrunner-common/netrunner-settings-theming/blob/master/usr/share/default-settings/plasma5-profile/kwinrc
This certainly has setting combinations which I consider as unsupported. To me any strong deviation is considered unsupported. We don't have the manpower to ensure that the weird combinations work. To me that is fine, most of these options are hidden in expert modes showing warnings. If users select them: they were warned. If distros do it, it becomes problematic.
Especially I consider the following choices questionable:
AnimationSpeed=1
This disables all animations exposing repaint issues in case the animations hid them.
UnredirectFullscreen=false
Doesn't exist any more, why include it?
slidingpopupsEnabled=false kwin4_effect_maximizeEnabled=false kwin4_effect_translucencyEnabled=false
These are all effects enabled by default in Plasma. Using with them disabled, well might work, might not. Nobody of us ever tested it. They all animate, so can hide repaint issues.
and not to mention all the values which match the default values. Alas that's something I brought up every half year when still having been with BlueSystems. And every half year we have to investigate the weird brokeness this procedure creates.
To me the result of this is that we need to cut down on the configuration possibilities. We don't have the possibility of testing all of them. If three devs have to work on trying to figure out what causes a repaint glitch which nobody else has ever seen before than the result is that we need to cut down to a managable subset of options.
well, to me really becomes reproducible from time to time just disabling the translucency effect, which, not wanting the window semitransparent when moved aound, is fine and should be supported.
another interestng thing i noted in the bug that occurs when moving a window: it happens only the first time a particular window is moved, after that time, for the whole lifecycle of the window, the problem is not reproducible
in
void AbstractClient::addRepaintDuringGeometryUpdates()
the first time a window moves, that's when the bug occurs, i get a smaller geometry.
that's a debug of the values m_visibleRectBeforeGeometryUpdate and deco_rect
QRect(274,423 1062x552) QRect(256,410 1092x582)
QRect(256,410 1092x582) QRect(255,410 1092x582)
QRect(255,410 1092x582) QRect(251,409 1092x582)
QRect(251,409 1092x582) QRect(248,409 1092x582)
that suggests the first time the shadow was *not* taken into account