Bug 356343

Summary: Rendering issue after upgrade to kwin 5.5
Product: Breeze Reporter: Weng Xuetian <wengxt>
Component: QStyleAssignee: Hugo Pereira Da Costa <hugo.pereira.da.costa>
Status: RESOLVED FIXED    
Severity: normal CC: grgoffe, henryju, hugo.pereira.da.costa, johannespfrang+kde, kde, Luc.Lalonde, mgit986, rdieter, slartibart70, terry, thomas.luebking
Priority: NOR    
Version: 5.5.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Screenshot that shows the problem

Description Weng Xuetian 2015-12-06 22:22:28 UTC
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.
Comment 1 Weng Xuetian 2015-12-06 22:23:01 UTC
Created attachment 95918 [details]
Screenshot that shows the problem
Comment 2 Thomas Lübking 2015-12-06 22:42:24 UTC
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)
Comment 3 Weng Xuetian 2015-12-06 23:48:04 UTC
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.
Comment 4 Martin Flöser 2015-12-07 09:35:00 UTC
* do you only get the rendering issues with konsole or also other applications?
* did you recently also update other components, e.g. Qt?
Comment 5 Thomas Lübking 2015-12-07 19:02:40 UTC
Also try
   KWIN_USE_BUFFER_AGE=0 KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &
Comment 6 Weng Xuetian 2015-12-07 23:58:55 UTC
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.
Comment 7 Weng Xuetian 2015-12-08 00:34:39 UTC
First bad commit in breeze found by git bisect.

http://commits.kde.org/breeze/6d852f30a1f2c1988359d4e0cdb21e2f1714a6bd
Comment 8 Thomas Lübking 2015-12-08 08:42:36 UTC
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)?
Comment 9 Hugo Pereira Da Costa 2015-12-08 09:16:17 UTC
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
Comment 10 Thomas Lübking 2015-12-08 12:25:22 UTC
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)
Comment 11 Hugo Pereira Da Costa 2015-12-08 12:48:21 UTC
(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.
Comment 12 Thomas Lübking 2015-12-08 20:47:58 UTC
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 ^_^
Comment 13 Weng Xuetian 2015-12-08 21:43:05 UTC
(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/ .
Comment 14 Hugo Pereira Da Costa 2015-12-15 23:41:32 UTC
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
Comment 15 Weng Xuetian 2015-12-16 02:44:50 UTC
I can confirm that this fixes the issue for me, thanks!
Comment 16 Johannes Pfrang 2016-01-04 00:08:53 UTC
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.
Comment 17 Hugo Pereira Da Costa 2016-01-11 19:20:57 UTC
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
Comment 18 Thomas Lübking 2016-01-25 10:25:07 UTC
*** Bug 357388 has been marked as a duplicate of this bug. ***
Comment 19 Rex Dieter 2016-01-28 11:46:31 UTC
*** Bug 357063 has been marked as a duplicate of this bug. ***
Comment 20 Luc Lalonde 2016-01-29 19:45:12 UTC
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!
Comment 21 Wolfgang Bauer 2016-01-30 11:43:20 UTC
*** Bug 358555 has been marked as a duplicate of this bug. ***