Decoration artifact on hovering

[kupiqu]

Please see the attached screenshot:

No idea where these artifacts come from. They seem to happen randomly, always on hovering, and then stay there. This happens for both active and inactive windows. The number of buttons affected seems quite random too, sometimes they affect just one button (like in the screenshot), sometimes 2 or 3 consecutive buttons.

It could be an upstream bug in breeze, kwin or qt, but somehow I failed to reproduce the issue in breeze.

[tsujan]

Can't reproduce, although I only use BreezeEnhanced.

Are you sure you've compiled it against the same version of KWin? V5.14 shouldn't be compiled with older KWin versions.

[tsujan]

@trmdi Sorry to bother you! Can you reproduce this issue?

[kupiqu]

Yes, I compile BreezeEnhanced against plasma 5.14

It may be driver dependent, perhaps?

[tsujan]

It may be driver dependent, perhaps?

I don't think so.

Is button spacing 6px in your case? Maybe you could attach ~/.config/breezerc as a zip file here for me to test it later.

[kupiqu]

[Common]
OutlineCloseButton=false
ShadowStrength=89

[Style]
ScrollBarAddLineButtons=0
ScrollBarSubLineButtons=0
WindowDragMode=WD_MINIMAL

[Windeco]
ButtonHPadding=4
ButtonSpacing=0
DrawBackgroundGradient=false
DrawSizeGrip=false
DrawTitleBarSeparator=false
TitleAlignment=AlignRight
TitleBarFont=Cabin [IMPA],10,-1,5,50,0,0,0,0,0
matchColorForTitleBar=false

[tsujan]

Thanks! I'll test it as soon as I find some time -- being very busy right now.

[kupiqu]

thank you

[tsujan]

I tested with your configuration but everything was OK. I wasn't able to find anything in the code that might cause the problem you described: ~90% of the code is that of Breeze and a simple animation shouldn't cause this. If your driver had a problem, you would see similar effects elsewhere (do you?).

So, for now, the only things that come to my mind are that you might want (1) to test with another KDE color scheme or (2) to recompile BreezeEnhanced and restart KWin.

I'll keep this open to see if others encounter it or if something else comes to my mind.

[trmdi]

Sorry, I don't see any problem with that screenshot ???

[tsujan]

A part of the background of the button at the middle is transparent. I've never seen that here.

[trmdi]

Do you mean the blue border around the middle buton ? I've never seen that too. @kupiqu Did you try turning off the vsync or change the openGL version in SystemSetting > Compositor?

[tsujan]

Do you mean the blue border around the middle buton ? I've never seen that too.

Yes. I think if there is a problem with grahic driver or vsync, @kupiqu should see similar issues in other places too.

[kupiqu]

I think it may be driver-dependent, although I didn't notice any issue elsewhere. Changing Vsync didn't help, neither modifying the OpenGL version, but I don't see the artifacts when I instead use XRender.

It all seems to indicate this is an upstream issue, so think I'll close the issue for now while I explore the root cause further...

Thank you @tsujan and @trmdi for your feedback!

[ripefig]

@tsujan I can reproduce this. This happens when the blur desktop effect is enabled and happens more frequently when you use window shading. Shade a window (I have unshade on hover too) and you should see this. I have Open GL 2.0 and integrated graphics.

Maybe make a version without transparency? That seems to be cause.

[tsujan]

@ripefig, thanks for your feedback! Now, I really think this may be related to the graphic driver/settings because I've NEVER seen it here. I can't think of anything in BreezeEnhanced that might cause it: the animation was already there; I just made use of it. But the quality of the blur effect is highly dependent on the graphic driver/settings.

That being said, I keep it in mind. Please let me know if it disappears with a KDE/KWin upgrade or a change in graphic driver/settings.

[kupiqu]

I really think this may be related to the graphic driver

I agree

EDIT: Or a bug in the graphic driver, or a bug in kwin

[tsujan]

or a bug in kwin

That's quite possible. In 2017, I couldn't use KWin because it was so lagging, while I had a powerful computer. I reported the problem but no solution was found. A year later, the problem was completely gone after multiple upgrades. Since then, I use nothing but KWin.

[kupiqu]

That's quite possible. In 2017, I couldn't use KWin because it was so lagging, while I had a powerful computer. I reported the problem but no solution was found. A year later, the problem was completely gone after multiple upgrades. Since then, I use nothing but KWin.

Reminder to ourselves (/me and @ripefig): we should check this out in wayland...

[kupiqu]

Reminder to ourselves (/me and @ripefig): we should check this out in wayland...

I do think it's a kwin bug, no need to go wayland actually, because exactly the same animations in the applet-window-buttons never create such artifacts

[kupiqu]

I filled a bug in kde about this: https://bugs.kde.org/show_bug.cgi?id=401492

[trmdi]

But I guess it would be very difficult to make they test 3rd party plugins. Furthermore, not everyone has this bug. You have to find a reliable way to reproduce it.

[kupiqu]

well, I guess it depends on how much evidence we report suggesting that the issue is in kwin (even though it is hidden by the fact that vanilla breeze does not have button animations), and mentioning about plasma, where the same animations work fine seems to indicate so.

[trmdi]

@kupiqu @ripefig Did you try some workarounds in this? https://wiki.archlinux.org/index.php/intel_graphics#Troubleshooting

Also, there is a note there:

Note: Some (Debian & Ubuntu, Fedora, KDE) recommend not installing the xf86-video-intel driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs.

[kupiqu]

But I guess it would be very difficult to make they test 3rd plugins. Furthermore, not everyone has this bug. You have to find a reliable way to reproduce it.

I can reproduce it all the time in my system. To reproduce it, you need intel+opengl, but yes, most likely not all intel+opengl cause the artifacts. Added more info to kde bug...

[kupiqu]

Did you try some workarounds in this? https://wiki.archlinux.org/index.php/intel_graphics#Troubleshooting

I took a look but that is incompatible with xserver-xorg-video-intel-native-modesetting, that is i915 integrated with the linux kernel which seems to be recommended by ubuntu and intel

I did upgrade the kernel from 4.15 to 4.18 to see if there was any improvement, but no luck

[trmdi]

I took a look but that is incompatible with xserver-xorg-video-intel-native-modesetting, that is i915 integrated with the linux kernel which seems to be recommended by ubuntu and intel

I did upgrade the kernel from 4.15 to 4.18 to see if there was any improvement, but no luck

Did you try xserver-xorg-video-intel instead of the recommended one? (I'm not sure about the name, but I mean the non-modesetting one)

[kupiqu]

Did you try xserver-xorg-video-intel instead of the recommended one?

No, I didn't want to mess with it. At least not at this time... But I may try it out, will see.

[trmdi]

Did you try xserver-xorg-video-intel instead of the recommended one?

No, I didn't want to mess with it. At least not at this time...

I've just checked, I'm using it.

[kupiqu]

I've just checked, I'm using it.

Which one, Kernel or Xorg?

[trmdi]

I've just checked, I'm using it.

Which one, Kernel or Xorg?

The non-modesetting one: xf86-video-intel which is not recommended by Ubuntu.

[kupiqu]

What options do you have in xorg.conf? for the case I want to give it a try

[trmdi]

What options do you have in xorg.conf? for the case I want to give it a try

Just this:

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
EndSection

(https://wiki.archlinux.org/index.php/intel_graphics#Xorg_configuration)

But it could depend on your driver, you should play with workarounds/tips/tricks... in the link I posted above.

[kupiqu]

nothing really special I see :/ I may try it.

you could also try using kernel's intel driver to see if you can replicate the issue...

[trmdi]

nothing really special I see :/ I may try it.

you could also try using kernel's intel driver to see if you can replicate the issue...

Yep, that only means I explicitly setup Xorg to use intel driver instead of the modesetting one.

When you try the intel driver, you should play with options mentioned in that link: AccelMethod, TearFree... (in the Troubleshooting section)

[kupiqu]

No luck, at least with just the vanilla setup. Playing with options might help but that is like seeking a needle in a haystack :(

[kupiqu]

Early to say, but seems that uxa instead of sna fixes the issue. Will continue checking this tomorrow...

[tsujan]

If it helps, the output of inxi -G here:

Graphics:  Device-1: Intel HD Graphics 530 driver: i915 v: kernel 
           Device-2: NVIDIA GM107M [GeForce GTX 960M] driver: N/A 
           Display: server: X.Org 1.20.3 driver: modesetting unloaded: intel resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) v: 4.5 Mesa 18.2.5 

In System Settings → Display and Monitor → Compositor, I have:

• Enable compositing on startup = checked.
• Animation speed slider = at the middle.
• Scale method = Accurate.
• Rendering backend = OpenGL 3.1.
  • vsync = Automatic.

---

The Intel driver also worked fine with the following settings but I didn't test it for a long time -- instead, I chose modesetting.

Section "Device"
    Identifier  "Device0"
    Driver      "intel"
    BusID       "PCI:0:2:0"
    Option      "AccelMethod" "sna"
    Option      "DRI"    "true"
EndSection

[tsujan]

EDIT: I updated the output of inxi -G -- had pasted an old output ;)

[kupiqu]

I don't think these options in xorg will fix the issue for me, as sna and dri true are enabled by default, so setting them explicitly won't change behavior.

But, another user reported in the KDE bug that he stopped seeing the artifacts in Qt Version 5.12.0 RC1... so this may be a Qt bug in the end. Let's hope this is confirmed...

[tsujan]

After this discussion, I can refer users to https://bugs.kde.org/show_bug.cgi?id=397215 , as a proof that shows this isn't about BreezeEnhanced.

I've seen not very different artifacts in Qt widgets that have translucency only when the value of QT_SCALE_FACTOR is non-integer -- for example, 1.5, 2.5,.... Recently, I started to support non-integer scale factors in Kvantum and saw artifacts in widgets for which translucency was enabled, especially in menus. I found and added a workaround to Kvantum but menus and item-views weren't completely fixed by it. I can't say they are related to this issue because they happen only with non--integer scale factors (which I never use -- I just test them). This shows that there is a bug in Qt. Whether there is any relation between it and the current Breeze bug, I can't tell because there are too many factors at work.

BTW, I use the LTS kernel 4.19 -- I always use LTS kernels, previously 4.14.

[kupiqu]

translucency

I see, so it might be caused by translucency, not necessarily by the animation.

I guess it's difficult to understand at first sight, though, why this is different between kwin and plasma (i.e., applet-window-buttons)

[tsujan]

why this is different between kwin and plasma

I don't know but, in both cases of Breeze and non-integer scale factors, the calculations are done in terms of qreal (double), so that the final result is anti-aliased. It seems that, in such cases, non-integer values are replaced by wrong integers. Just a wild guess...

[kupiqu]

But, another user reported in the KDE bug that he stopped seeing the artifacts in Qt Version 5.12.0 RC1... so this may be a Qt bug in the end. Let's hope this is confirmed...

Same user reported he saw the issue again (in Qt Version 5.12), so Qt doesn't fix it

[ripefig]

@tsujan The problem is gone after upgrading the rendering backend to OpenGL 3.1. I've only experienced this bug on OpenGL 2.0

[kupiqu]

The problem is gone after upgrading the rendering backend to OpenGL 3.1. I've only experienced this bug on OpenGL 2.0

Not in my case I suffer it in both. Try kwin --replace and check it again.

EDIT: Only workaround for me is using 'uxa', no other workaround has fixed the issue for me.

[tsujan]

The problem is gone after upgrading the rendering backend to OpenGL 3.1

Apparently, different systems need different settings. I'm happy with modesetting and OpenGL 3.1 when it comes to KWin. But when I used Compiz-reloaded (on LXQt), I needed the Intel driver and DRI2, maybe because Compiz-reloaded's code was old.

[ripefig]

@kupiqu @tsujan. Yeah, I lies OpenGL 3 causes the same problem, just less frequently.

The artifact is probably caused by the transparency feature (which I have turned off). The little artifacts are actually transparent and blurred. The whole problem seems to go away if blur effect is disabled or if your switch to regular breeze, which doesn't support transparency.

[ripefig]

@tsujan maybe consider making a version without transparency? that's what causing the bug.

[tsujan]

that's what causing the bug.

Translucency can't cause any bug.

[ripefig]

hmm, but this isn't observed in the breeze decoration. the artifacts are in fact translucent. there is also a little artifact in the corner..

breeze enhanced:

vs

breeze: