Bug 360978 - Tooltips (task manager, system tray) are rendered incorrectly
Summary: Tooltips (task manager, system tray) are rendered incorrectly
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: 5.5.95
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-25 20:18 UTC by Martin Höher
Modified: 2018-08-18 08:02 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot showing an incorrectly rendered tooltip. (1.79 MB, image/png)
2016-03-25 20:19 UTC, Martin Höher
Details
Output of `qdbus org.kde.KWin /KWin supportInformation` (5.35 KB, text/plain)
2016-04-03 19:12 UTC, Martin Höher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Höher 2016-03-25 20:18:17 UTC
After updating to Plasma 5.5.95, the tooltips are rendered incorrectly. This is most notable with the task manager, but also visible with the system tray (I guess also everything else providing tooltips is affected).

When e.g. moving the mouse cursor between different entries in the task manager, the tooltips get rendered incorrectly. The problem seems to occur only when I am not on the virtual desktop 1. As soon as I change to virtual desktop 1, the tooltips are rendered as expected.

Reproducible: Always

Steps to Reproduce:
1. Switch to a virtual desktop other than desktop 1.
2. Move the mouse cursor e.g. over an entry in task manager and wait for the tool tip to appear.
3. Move the mouse to another task manager entry.

Actual Results:  
The tooltip is rendered incorrectly. It looks like the rectangle is split up into multiple pieces.

Expected Results:  
The tooltip is rendered correctly.

I am using the beta RPMs from the KDE SIG Copr repository: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-5-unstable/
Comment 1 Martin Höher 2016-03-25 20:19:26 UTC
Created attachment 98077 [details]
Screenshot showing an incorrectly rendered tooltip.
Comment 2 Martin Höher 2016-04-03 16:35:08 UTC
I just realized that the problem does not appear if the "Morphing Popups" effect is turned off in System Settings -> Desktop Effects.
Comment 3 Kai Uwe Broulik 2016-04-03 16:46:41 UTC
Thanks, re-assigning to KWin and CC'ing Marco who wrote the morphing popups effect.
Comment 4 Thomas Lübking 2016-04-03 18:18:39 UTC
Looks more like insufficient repaint areas, but
a) that should affect more effects
b) the relation to the VD seems a bit odd.

please attach the output of "qdbus org.kde.KWin /KWin supportInformation" and try whether this also remains w/ the morphing effect en-, but the blur and contrast effects disabled.
Comment 5 Martin Höher 2016-04-03 19:12:12 UTC
Created attachment 98223 [details]
Output of `qdbus org.kde.KWin /KWin supportInformation`
Comment 6 Martin Höher 2016-04-03 19:13:35 UTC
As recommended, I tried to disable the blur and contrast effects and enabling the morphing popups effect, but the issue remains.
Comment 7 Thomas Lübking 2016-04-03 19:18:01 UTC
> OpenGL platform interface: EGL
"kcmshell5 kwincompositing", I bet your right arm it doesn't happen with the GLX backend.

Check /var/log/Xorg.0.log on whether DRI3 is enabled and if not, try to do  so.
Comment 8 Martin Höher 2016-04-03 19:26:49 UTC
Switching to GLX did not change anything. What I just noticed is that the issue also occurs on VD1, so this was a false trace (dunno why it did not seem to happen on VD1 before, though...).

Regarding DRI3, this is what I found in the X log:

[    14.847] (II) intel(0): direct rendering: DRI2 DRI3 enabled

So I guess DRI3 is in fact enabled already.
Comment 9 Martin Flöser 2016-04-04 15:08:27 UTC
please also try using OpenGL 2 in KWin's compositing settings.
Comment 10 Thomas Lübking 2016-04-04 15:53:59 UTC
Sorry for your arm :-P

My guess is that the animation gets retargetted (seems to be quite required reg. the tooltips)
Not only is this the least tested feature, but I assume that altering the from to the current position drops the region between the last interpolated position and the interpolated position at the repaint.

The most simple solution should be to add a complete (full scene) layer repaint when an animation is retargetted.
If that works, one could seek into actually capturing the dropped geometry.
Comment 11 Martin Höher 2016-04-04 17:43:27 UTC
No problem, survived worse ;)

Regarding OpenGL: I tried to switch to 2.0 which does not change anything. Switching to XRender makes some difference (there are still fragments seen on the screen, but compared to OpenGL - where the fragments are kind of flickering - with XRender the fragments are drawn steadily).
Comment 12 Martin Höher 2016-07-25 19:50:22 UTC
Hey guys,

I just wanted to let you know that after running an update today to Plasma 5.7.1 (from Fedora packages) the described issue seems to be gone :-) So whatever fixed it: Thank you a lot (also in general, so far I love the 5.7 release)!

Ciao
Martin
Comment 13 Vlad Zahorodnii 2018-08-18 08:02:09 UTC
Marking it as resolved.