D27439: Replaced isDock check with !hasDecoration

[Niccolò Venerandi]

niccolove added a comment.


  In D27439#612897 <https://phabricator.kde.org/D27439#612897>, @zzag wrote:
  
  > Bad wording, sorry. The main problem with the blur effect right now is that pixels nearby the blur region may affect the final blur result. For example, if you place two windows side by side, then the window with the highest stacking order will blur some parts of the other window. Perhaps we need to blur pixels that are strictly inside the blur region. I'm not sure what performance impact it will have and how we should deal with drop-shadows, though.
  
  
  Only blurring elements directly underneath was my first though as well. This has a problem, though: when you move a blurred area on top of a busy area (e.g.: transparent konsole on top of telegram) the borders of the blurred area flicker. This is because elements gets from "does not even exist" to "blurred" as soon as they get in the blur area completely changing the colors of the pixel within the blur radius instantaneously. I can say that because the feature of "only blurring when directly underneath" is already implemented for docks. To use it for any window, it's enough to change line 689 from "isDock" to "true". Doing that, you will notice the above mentioned effect. What I propose in this patch is to only apply the "only blur when directly underneath" for anything that has not a decoration, so plasmoids+krunner+context menus as well. We can safely do that as those elements generally do not move (the flickering is not present in animations) and when you try to move a window they close. Furthermore, this only happens on very transparent themes. So what you propose is to do "only blur underneath" for everything, while this patch is "only blur underneath" exclusively for noDecoration - if you think that applying it for everything is fine, only applying it to noDecoration should be fine as well. I tried this patch in various conditions and the only problem that I could find is when you a) have a very transparent theme b) move windows underneath plasmoids/krunner using alt+drag, and even in that case the flickering is not that strong; in my opinion, the overall benefit for everyone is much bigger.
  I hope this better explains the reasoning behind this patch. I'm not an expert at all with kwin so please tell me if I'm making invalid assumptions. That said, what I observed changing the code was consistent with what I wrote above.
  
  I tried to make a video to show the flickering of turning it on for everything, but my PC apparently can't record my screen. Still, it might make the concept a bit more clear:
  F8112825: blurproblem.gif <https://phabricator.kde.org/F8112825>

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D27439

To: niccolove, #kwin, zzag, davidedmundson
Cc: davidedmundson, ngraham, kwin, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20200219/d2c6e6bf/attachment.html>