Background of system tray icons not drawn properly

Bug #1797417 reported by Boris Gjenero on 2018-10-11
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Xfce4 Panel
Fix Released
Medium
xfce4-panel (Ubuntu)
Undecided
Unassigned

Bug Description

In Ubuntu 18.04 this problem did not exist. After upgrading to 18.10 the backgrounds of system tray icons in the Xfce panel are not drawn properly on my Inspiron 6400 laptop with ATI/AMD Mobility Radeon X1400 graphics and the open source radeon driver. This problem does not exist in 18.10 on my main PC with Nvidia 8600GT and their proprietary drivers.

The background of the system tray icons is not simply black. Look at the network icon. The previous contents of the icon are visible behind the WiFi signal bars.

Though, now that I tried installing libxfconf-0-2_4.12.1-1_amd64.deb and xfce4-panel_4.12.2-1ubuntu1_amd64.deb from Ubuntu 18.04 I see some glitches in the system tray, though not as bad.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: xfce4-panel 4.13.3-1ubuntu1
ProcVersionSignature: Ubuntu 4.18.0-8.9-generic 4.18.7
Uname: Linux 4.18.0-8-generic x86_64
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu Oct 11 12:04:26 2018
InstallationDate: Installed on 2012-01-19 (2457 days ago)
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: xfce4-panel
UpgradeStatus: Upgraded to cosmic on 2018-10-11 (0 days ago)

Created attachment 7858
Screenshot

When compositing is disabled, icons within notification area are not drawn properly.

A good test case is Gnome's network-manager-applet: Do disconnect and connect again -> the green 'balls' and their shadows remain visible (see screenshot attached). Have checked: Enabling compositor works without issues.

It took me a while to trace this down to xfce4-panel/systray: A look into systray.c made me aware: In systray_plugin_box_draw() and systray_plugin_box_draw_icon() there are checks that look to me as if icons are not redrawn if compositing is not enabled - but I am no expert and not sure my suspicion is correct.

Maybe it is same issue as reported in https://bugzilla.xfce.org/show_bug.cgi?id=14397

I'm almost certain it's a dup of Bug 14438, but let's keep this open for now, I would like to be sure that people working on panel (Simon, Sean?) are aware of your analysis.

Found interesting GNOME stories:

* GNOME tray ICON is missing background [1]
* The problem mentioned here was found at GNOME too [2].
* A GTK patch [3] that came in with gtk 3.24.0 (Side note: GNOME docs still mention explicitly that 'background of NULL means that the window will inherit its background from its parent window' [4] - which definitely not true anymore)

Looking at the xfce4-panel's code in plugins/systray/systray-socket.c / systray_socket_realize (GtkWidget *widget) I think:

* As soon as GTK >= 3.24 is installed, background for systray will not be painted anymore
* Looking again at the patch [3] gives me an idea why some users had the problem and some not with GTK < 3.24: Those with depth of icon == depth of parent window were fine. Others already saw missing background (and uncleaned 'leftovers').

Hope that helps - although I get the feeling a fix not trivial...

[1] https://gitlab.gnome.org/GNOME/gtk/issues/1280
[2] https://gitlab.gnome.org/GNOME/gtk/issues/1319
[3] https://gitlab.gnome.org/GNOME/gtk/commit/01d1bc3c75fd0eff5665f5b9c690c5e1e6c65f13
[4] https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-background-pattern

I would like to confirm downgrading to gtk3-3.22 and the icon problem isn't present. Tested on a few workstations that have had this problem since the gtk3 package update on ArchLinux.

Boris Gjenero (boris-gjenero) wrote :

Does this happen regardless of having compositing enabled or disabled?

Settings > Window Manager Tweaks > Compositor

Boris Gjenero (boris-gjenero) wrote :

Compositing was disabled. When I enabled it, the problem was fixed instantly. I have not seen any more signs of the problem with compositing enabled. Thank you.

Boris Gjenero (boris-gjenero) wrote :

My main computer with GeForce 8600 GT and driver 340.107-0ubuntu2 had Compton compositor running via Application Autostart in Session and Startup. Disabling that, logging out and logging back in brings up some corruption there as well.

@Andreas: Your analysis seems sound, but to be honest this seems to be an issue within Gtk+3, I'm not sure how we can properly work around this in the panel reliably and without introducing ugly hacks.

This may not sound encouraging, but I'm tempted to wait for Gtk+ devs to fix this in their toolkit...

*** Bug 14438 has been marked as a duplicate of this bug. ***

*** Bug 14397 has been marked as a duplicate of this bug. ***

Changed in xfce4-panel:
importance: Unknown → Medium
status: Unknown → Confirmed

Should be fixed in GTK+ 3 (gtk-3-24 branch, will be in 3.24.2) and in Arch with gtk3-3.24.1+155+g4c8fcd6a6f-1.

Unless Andreas was seeing this with GTK+ 3.22 or older, I don't believe there is anything to fix on Xfce's side.

Just to note that the above fix caused serious breakage in some applications when using a compositor. [1] I reverted it in Arch for now. :\

[1] https://gitlab.gnome.org/GNOME/gtk/issues/1280#note_384582

@Evangelos: Is this one related? https://bugzilla.xfce.org/show_bug.cgi?id=14186
(Note that compositing is enabled there)

And this one seems to be a duplicate too... https://bugzilla.xfce.org/show_bug.cgi?id=14936

Bug 14936 is almost certainly a duplicate of this one.

I'm not sure what's going on in bug 14186. With compositing enabled, there should be no issues with tray icon backgrounds.

*** Bug 14936 has been marked as a duplicate of this bug. ***

TL;DR Downgrading to gtk+ 3.22 doesn't fix this issue for me.

I just had time to try downgrading gtk+ to test if this was fixing this issue here. I first downgraded gtk+ to 3.22.30, then to 3.22.19 (the oldest gtk+ 3 in Gentoo), then tried rebuilding all core XFCE packages against gtk+ 3.22.19, rebooted every time I tested, and none of that fixed it. Am I missing something?

(In reply to Denis Dupeyron from comment #13)
> TL;DR Downgrading to gtk+ 3.22 doesn't fix this issue for me.
>
> I just had time to try downgrading gtk+ to test if this was fixing this
> issue here. I first downgraded gtk+ to 3.22.30, then to 3.22.19 (the oldest
> gtk+ 3 in Gentoo), then tried rebuilding all core XFCE packages against gtk+
> 3.22.19, rebooted every time I tested, and none of that fixed it. Am I
> missing something?

3.22.30 worked for me on ArchLinux, did not need to rebuild any of xfce4 packages. Are you certain you've cleared out everything from 3.24?

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfce4-panel (Ubuntu):
status: New → Confirmed
S4qFBxkFFg (s4qfbxkffg) wrote :

I just upgraded to 19.04 (Disco) and still see this behaviour (black background to system tray icons in XFCE).

MMarking (cpt-mocha) wrote :

Ditto on upgrade to 19.04 from 18.10. Same issue....

i'm on gtk3-3.24.8-1.fc30.x86_6 on fedora and still the distorted images.

Created attachment 8663
screenshot

gtk3.24.8+177+gae2ef1472c-1 here on Arch, only network-manager-applet is weird when compositing is disabled.

I just installed gtk3.24.9 in fedora but the issues remains.
No matter which apps, the issues aren't consistent but it's either a black background or redraw issues (either the icon moved to the side for a new one or by changing icon themes and the old icon still partially visible underneath) or both.
Compositing disabled, but that's a basic feature as compositing do take a toll on old hardware.

Although I'll try to stay with compositing enabled and all settings off. Probably that won't stress much or at all this old hardware (pentium e2160 and via s3 graphics) and could be the solution if this takes time to be fixed.

(In reply to Andre Miranda from comment #16)
> Created attachment 8663 [details]
> screenshot
>
> gtk3.24.8+177+gae2ef1472c-1 here on Arch, only network-manager-applet is
> weird when compositing is disabled.

I was playing with that again because I noticed that when playing a video in mpv my CPU was way more active that it should be: to make a long story short, both Xorg and xfwm4 use one full equivalent core each out of 4 on this core i7 laptop, and almost nothing with compositing off.

Anyway, I would have agreed with you about the issue being limited to nm-applet, until I found out that after a few back-and-forth of the compositing on/off setting I could make all the other icons in my panel go dark background and messed up. So, if all you see is a messed up nm-applet icon I want to say: try harder ;-)

This issue infuriates me, especially when I have to use my laptop on battery. I want to help but I don't know how to. It's nice and all, and may be entirely justified, to blame gtk for the issue, but at some point, if it's limited to the xfce4-panel I can't imagine the gtk aka gnome people being sympathetic to the situation. I think in this case we need to admit gtk will never care enough to fix it and xfce4-panel will have to apply local fixes.

I can understand you guys being time limited. But could you please give us here some pointers as to where to start looking? The OP talked about systray_plugin_box_draw() and systray_plugin_box_draw_icon() in systray.c, is that correct?

(In reply to Denis Dupeyron from comment #19)
> Anyway, I would have agreed with you about the issue being limited to
> nm-applet, until I found out that after a few back-and-forth of the
> compositing on/off setting I could make all the other icons in my panel go
> dark background and messed up. So, if all you see is a messed up nm-applet
> icon I want to say: try harder ;-)
I didn't mean "this is a nm-applet bug", I meant that this is still an issue that I can reproduce with nm-applet.

> I can understand you guys being time limited. But could you please give us
> here some pointers as to where to start looking? The OP talked about
> systray_plugin_box_draw() and systray_plugin_box_draw_icon() in systray.c,
> is that correct?
I spent over two hours playing with those functions and systray_socket_draw/systray_socket_force_redraw to no avail. I also tried to call those functions or gtk_widget_queue_draw every second (g_timeout_add), no difference. No matter what I change the systray background is never cleared.
This bug seems to require a better knowledge of gtk/cairo than mine (which is not great anyway), availability to spend more time investigating or both.

I noticed this issue resurfaced again after updating gtk3 and xfce4 on ArchLinux. Enabling compositing and it goes away immediately. Turn it off and redrawing of icons turns into a strange mixture / mess of icons. Initially, all icons in the notification area had black background, regardless of theme setting.

Package versions:
* gtk3 1:3.24.10-1
* xfce4-panel 4.14.0-1

*** Bug 15821 has been marked as a duplicate of this bug. ***

I'm also experiencing this issue on Arch Linux with xfce4-panel 4.14.0-1 and gtk3 1:3.24.10-1. I'm able to fix the issue by enabling compositing, which I prefer to have switched off. I've uploaded screenshots here: https://imgur.com/a/5KvhHA3

Also experiencing this bug on Arch Linux with xfce4-panel 4.14.0-1 and gtk3 1:3.24.10-1.

Please don't take this personally but "it affects me too" comments aren't helpful anymore at this point.

It's a known issue, so I expect it affects everyone. If you're the exception, please raise your voice! Otherwise please don't give in on the temptation to add your +1 as it makes the bugreport harder to read and consequently less helpful.

In any case, I acknowledge the problem and if I see a way to fix it, I will.

Thanks!

Good news. Linux Mint team are developing a cross platform/cross desktop panel tray technology.

https://blog.linuxmint.com/?p=3795

In , Iv-n (iv-n) wrote :

I'm also affected by the problem, with gtk+3 3.24.11 and xfce4 panel 4.14.0.

When I run xfce4-panel with PANEL_DEBUG=systray I see the following in the debug log:

xfce4-panel(external): xkb-3: child is embedded; 7 properties in queue
xfce4-panel(systray): registered manager on screen 0
xfce4-panel(systray): socket networkmanager applet[0x1244f30] (composited=false, relative-bg=false
xfce4-panel(systray): added networkmanager applet[0x1244f30] icon
xfce4-panel(systray): socket clipman[0x14fe490] (composited=false, relative-bg=false
xfce4-panel(systray): added clipman[0x14fe490] icon

I tried to dig into that a bit and that lead me to systray_socket_realize function:

https://git.xfce.org/xfce/xfce4-panel/tree/plugins/systray/systray-socket.c?h=xfce-4.14.0#n122

Yes, we're not compositing, as the compositing is disabled, so this is expected. But relative-bg is not set, too -- apparently, the visuals of the socket widget and its parent differ. And indeed, they are. Here is a part of my gdb session:

(gdb) step
gtk_widget_get_visual (widget=0x434f30) at gtkwidget.c:11685
11685 g_return_val_if_fail (GTK_IS_WIDGET (widget), NULL);
(gdb) finish
Run till exit from #0 gtk_widget_get_visual (widget=0x434f30) at gtkwidget.c:11685
0x00007ffff7fc3dd8 in systray_socket_realize (widget=0x434f30) at systray-socket.c:139
139 else if (gtk_widget_get_visual (widget) ==
Value returned is $7 = (GdkVisual *) 0x43c590
(gdb) step
gdk_window_get_parent (window=window@entry=0x6f20c0) at gdkwindow.c:2436
2436 g_return_val_if_fail (GDK_IS_WINDOW (window), NULL);
(gdb) finish
Run till exit from #0 gdk_window_get_parent (window=window@entry=0x6f20c0) at gdkwindow.c:2436
0x00007ffff7fc3de3 in systray_socket_realize (widget=0x434f30) at systray-socket.c:139
139 else if (gtk_widget_get_visual (widget) ==
Value returned is $8 = (GdkWindow *) 0x434900
(gdb) step
gdk_window_get_visual (window=0x434900) at gdkwindow.c:2288
2288 g_return_val_if_fail (GDK_IS_WINDOW (window), NULL);
(gdb) finish
Run till exit from #0 gdk_window_get_visual (window=0x434900) at gdkwindow.c:2288
0x00007ffff7fc3deb in systray_socket_realize (widget=0x434f30) at systray-socket.c:139
139 else if (gtk_widget_get_visual (widget) ==
Value returned is $9 = (GdkVisual *) 0x442850
(gdb) p *((GdkVisual *) 0x43c590)
$10 = {parent_instance = {g_type_instance = {g_class = 0x43c090}, ref_count = 2, qdata = 0x0}, type = GDK_VISUAL_TRUE_COLOR, depth = 24, byte_order = GDK_LSB_FIRST, colormap_size = 256, bits_per_rgb = 8, red_mask = 16711680,
  green_mask = 65280, blue_mask = 255, screen = 0x43a020}
(gdb) p *((GdkVisual *) 0x442850)
$11 = {parent_instance = {g_type_instance = {g_class = 0x43c090}, ref_count = 2, qdata = 0x0}, type = GDK_VISUAL_TRUE_COLOR, depth = 32, byte_order = GDK_LSB_FIRST, colormap_size = 256, bits_per_rgb = 8, red_mask = 16711680,
  green_mask = 65280, blue_mask = 255, screen = 0x43a020}

So, the widget has 24 bit visual, but it's parent has 32 bit visual, so no parent-relative background.

Hi Ivan, thanks for debugging - that sounds like a most likely cause.
I'm not sure I understand why yet, but at least that's a good direction to start searching.

Created attachment 9037
Always set parent-relative background

I'm not sure it's helpful to not set a parent-relative background when compositing is disabled, so I went for always enabling it.
This fixes the problem for me.

Please test the attached patch! Thanks

*** Bug 13948 has been marked as a duplicate of this bug. ***

(In reply to Simon Steinbeiss from comment #29)
> Created attachment 9037 [details]
> Always set parent-relative background
>
> I'm not sure it's helpful to not set a parent-relative background when
> compositing is disabled, so I went for always enabling it.
> This fixes the problem for me.
>
> Please test the attached patch! Thanks

Can't confirm, the icons are still corrupted with the patch applied to panel 4.14.0 and compositing disabled.

Ok, no need to test the patch. Unfortunately I was only looking at apps with 16x16 opaque icons, which looked fine.
So no, it doesn't work.

In , Iv-n (iv-n) wrote :

I also tried a few things. First, as far as I understood, parent-relative background is not set with NULL, there is a special pattern that should be used instead:

--- a/xfce4-panel/plugins/systray/systray-socket.c
+++ b/xfce4-panel/plugins/systray/systray-socket.c
@@ -139,7 +139,7 @@ systray_socket_realize (GtkWidget *widget)
   else if (gtk_widget_get_visual (widget) ==
            gdk_window_get_visual (gdk_window_get_parent (window)))
     {
- gdk_window_set_background_pattern (window, NULL);
+ gdk_window_set_background_pattern (window, gdk_x11_get_parent_relative_pattern());

       socket->parent_relative_bg = TRUE;
     }

This alone, of course, does not help, since the visuals of the window and its parent are different: systray manager uses 24-bit visual on my system, but all its parents, including the pannel and the plugin wrapper ("wrapper-2.0" window) use 32-bit RGBA visuals. I've hacked systray_manager_set_visual function to use RGBA visual, too (what gdk_screen_get_rgba_visual(screen) returns, if that's not NULL) -- and I believe this is the right thing to do -- but it confuses systray_socket_new which sees that the visual supports alpha channel and thinks we have compositing.

Has anyone tested if mate-panel exposes this bug too? If not, their code base is fairly similar, so the fix may be there...

Changed in xfce4-panel:
status: Confirmed → In Progress

I tested MATE in VirtualBox with compositing disabled and couldn't reproduce the panel icon problem.

In , Iv-n (iv-n) wrote :

Created attachment 9050
patch that fixes the problem on my machine

> I've hacked systray_manager_set_visual function to use RGBA visual,
> too (what gdk_screen_get_rgba_visual(screen) returns, if that's not NULL)
> -- and I believe this is the right thing to do -- but it confuses systray_socket_new
> which sees that the visual supports alpha channel and thinks we have compositing.

Well, apparently it was me who was confused: it seems that if visual supports alpha channel we actually are compositing, even if it does not happen on screen/wm level. But if so, we should not check that screen is composited in systray_plugin_box_draw, so I removed that check; when this check was present, icons were not drawn at all.

I'm attaching the patch with these two simple changes. Applying it to xfce4-panel 4.14.0 fixed the issue on my machine.

(In reply to Ivan A. Melnikov from comment #36)
> I'm attaching the patch with these two simple changes. Applying it to
> xfce4-panel 4.14.0 fixed the issue on my machine.

Works for me too, thanks!

In , Iv-n (iv-n) wrote :

By the way, mate-panel works in my configuration. And it uses 32-bit visuals for systray and icons.

It works here too on Gentoo and xfce4-panel-4.14.0. Thanks a lot Ivan!

Patch 9050 fixed the problem for me. Tested with volumeicon-alsa on ubuntu 19.04.

Thanks, Ivan!

In , Gitbot (gitbot) wrote :

Ivan A. Melnikov referenced this bugreport in commit f6f70cce417fd2982c2ce6f01016ed01deb6a9ae

systray: Fix icons without compositing (Bug #14577)

https://git.xfce.org/xfce/xfce4-panel/commit?id=f6f70cce417fd2982c2ce6f01016ed01deb6a9ae

In , Gitbot (gitbot) wrote :

Ivan A. Melnikov referenced this bugreport in commit 820de57c44c381e47091d3a7e214852bf8fafb53

systray: Fix icons without compositing (Bug #14577)

https://git.xfce.org/xfce/xfce4-panel/commit?id=820de57c44c381e47091d3a7e214852bf8fafb53

@Ivan: I reviewed and tested the patch, makes a lot of sense! Thanks a bunch for taking a look at this!

In , Iv-n (iv-n) wrote :

Simon, thank you for reviewing and merging.

Changed in xfce4-panel:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.