E.g start konsole maximized will render something behind it, and it can be captured by ksnapshot. Output of qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation http://paste.ubuntu.com/13764936/ Reproducible: Sometimes Steps to Reproduce: start konsole Actual Results: render issue will be uploaded in next attachment. Expected Results: renders correctly.
Created attachment 95918 [details] Screenshot that shows the problem
Wild guess: is it reproducible with the blur effect disabled? (If not, what if you disable "cache intermediate results" in the blur effects config dialog. It's the only checkbox)
I tried disabled blur, or enable blur but don't check "cache intermediate results" . Both can reproduce the problem. BTW it's not reproducible with composition disabled. But both XRender, GLX backend can reproduce this problem.
* do you only get the rendering issues with konsole or also other applications? * did you recently also update other components, e.g. Qt?
Also try KWIN_USE_BUFFER_AGE=0 KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &
Ok, now I discover something new. I tried to downgrade kwin only but problem was still there. But I tried to downgrade whole plasma group, it went back to normal. But once I get breeze updated to 5.5, with either version of kwin the problem appears. So this seems to be related to breeze theme. I tried to use breeze decoration with oxygen widget style, there's no problem, so probably related to breeze widget style. (In reply to Thomas Lübking from comment #5) > Also try > KWIN_USE_BUFFER_AGE=0 KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace & This doesn't help.
First bad commit in breeze found by git bisect. http://commits.kde.org/breeze/6d852f30a1f2c1988359d4e0cdb21e2f1714a6bd
The code seems to perform a (delayed) change of a widgets palette, but that doesn't explain why the window below paints on top (unless a part of the konsole window is repainted with full transparency) - or did I get that description wrong? Could be some false shape mask is applied? Does it also happen w/o compositing resp. can you interact with the below window (in the exposed area)?
Hi, Thanks for reporting and bisecting. I was about to say, the change looks pretty orthogonal to the issue at hand. But then again, the reason why this change was introduced, namely bug #344425 is not very clear either. (apparently, calling setPalette to a widget inside ::polish was breaking input events). Ultimately I would like to get rid of these palettes manipulation in breeze because they are broken in other ways (application palette changes of a given widget not properly propagated to children), but I think this issue is different and should be fixed regardless. I'm clueless how, though Hugo
How could anything in konsole match ::acceptWidget, why would that expose content on the window system layer and htf should palette setting mess with input??? There needs to be some other bug deeper down, I don't use networkmanager - could you reproduce the input breaking with anything else but plasma-nm? What I could assume is that ::adjustPalette makes a call to the winId though, and then nasty things can happen (which might also explain the window-from-below exposure) About palette updates: changes only impact children until the first child with Qt::WA_SetPalette is met in the tree (they don't inherit the parenting palette but start a new hierarchy)
(In reply to Thomas Lübking from comment #10) > How could anything in konsole match ::acceptWidget, why would that expose > content on the window system layer and htf should palette setting mess with > input??? > no clue > There needs to be some other bug deeper down, I don't use networkmanager - > could you reproduce the input breaking with anything else but plasma-nm? > nope > What I could assume is that ::adjustPalette makes a call to the winId > though, and then nasty things can happen (which might also explain the > window-from-below exposure) > not that I know. > > About palette updates: > changes only impact children until the first child with Qt::WA_SetPalette is > met in the tree (they don't inherit the parenting palette but start a new > hierarchy) Which is the issue: when the style calls setPalette on a given widget it starts a new hierarchy. If the application set a custom palette on a parent widget, it will propagate untill it hits one modified by the style and break there. Not good. We react on application palette change (using a trick, because the widgets for which we changed the palette manually do not get the corresponding change event anymore), but not on parent widgets palette change. Anyway. That's OT.
Outmost weird. Xuetian, how do you start konsole maximized (by restored size, kwin rule, kstart, some konsole key I don't know ... ;-) and does it matter whether you flag --notransparency to it? Can you also "qDebug() << object;" in the ::adjustPendingPalettes() loop to see what widgets there would actually be to fit this breeze code? PS: In case Xuetian is actually your surname - sorry ^_^
(In reply to Thomas Lübking from comment #12) > Outmost weird. > > Xuetian, how do you start konsole maximized (by restored size, kwin rule, > kstart, some konsole key I don't know ... ;-) and does it matter whether you > flag --notransparency to it? > > Can you also "qDebug() << object;" in the ::adjustPendingPalettes() loop to > see what widgets there would actually be to fit this breeze code? > > PS: In case Xuetian is actually your surname - sorry ^_^ I start konsole maximized just by closing konsole when it's maximized. It's easier to reproduce the issue when it's maximized (so nothing covers it or triggers repainting). With --notransparency, it seems that there's no problem anymore, even though my konsole profile doesn't use transparency. After add qDebug(), only shows some some qmenu http://paste.ubuntu.com/13836079/ .
Git commit c5e48d765ab7ea71b0a4e30fe6482ed7e7be026f by Hugo Pereira Da Costa. Committed on 15/12/2015 at 23:40. Pushed by hpereiradacosta into branch 'master'. - Removed palette helper. Special background for groupboxes, menus, etc is now handled directly in the painting routine rather than adjusting the palette. This was indeed breaking palette inheritance, and requiring hacks that apparently posed some performance regressions. - check documentMode to decide tab background color. Related: bug 356561 M +0 -1 kstyle/CMakeLists.txt M +2 -37 kstyle/breezehelper.cpp M +0 -13 kstyle/breezehelper.h D +0 -188 kstyle/breezepalettehelper.cpp D +0 -94 kstyle/breezepalettehelper.h M +43 -15 kstyle/breezestyle.cpp M +0 -4 kstyle/breezestyle.h http://commits.kde.org/breeze/c5e48d765ab7ea71b0a4e30fe6482ed7e7be026f
I can confirm that this fixes the issue for me, thanks!
This bug reappeared somehow, but is only reproducible on multi-monitor setups (for me by starting konsole on the 2nd monitor). Bug 357388 has been filed about that issue.
Git commit 2cae9359188af85ac884e2709c17592bc67b0e73 by Hugo Pereira Da Costa. Committed on 11/01/2016 at 19:20. Pushed by hpereiradacosta into branch 'Plasma/5.5'. - Removed palette helper. Special background for groupboxes, menus, etc is now handled directly in the painting routine rather than adjusting the palette. This was indeed breaking palette inheritance, and requiring hacks that apparently posed some performance regressions. - check documentMode to decide tab background color. Related: bug 356561 M +0 -1 kstyle/CMakeLists.txt M +2 -37 kstyle/breezehelper.cpp M +0 -13 kstyle/breezehelper.h D +0 -188 kstyle/breezepalettehelper.cpp D +0 -94 kstyle/breezepalettehelper.h M +43 -15 kstyle/breezestyle.cpp M +0 -4 kstyle/breezestyle.h http://commits.kde.org/breeze/2cae9359188af85ac884e2709c17592bc67b0e73
*** Bug 357388 has been marked as a duplicate of this bug. ***
*** Bug 357063 has been marked as a duplicate of this bug. ***
This bug (seen on dual-head setup) reared is solved for me since I upgraded to Plasma 5.5.4. Yay! I can come back from GNOME 3 purgatory and start using KDE again ;-) Thank You!
*** Bug 358555 has been marked as a duplicate of this bug. ***