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.
@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. ***
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?
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 > 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
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 > 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.
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...
I tested MATE in VirtualBox with compositing disabled and couldn't reproduce the panel icon problem.
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!
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!
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
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!
Simon, thank you for reviewing and merging.
I built Xfce-panel 4.14.1 for LinuxMint 19.3 'Tricia' (which has Xfce 4.14 by default) GTK 3.0-3.22.30 , as I had the same issue. But it still did not work out of the box. On checking bug #16106, I enabled compositing, brought the Enter and Leave opacity to 100, disabled Compositing, and restarted the panel and only then did this fix work for me.
@bpr95: Could you please try to reproduce with an empty, newly-created panel? Also, please export your panel config with xfce4-panel-profiles (or xfpanel-switch, whichever is present in your distro) and attach it so I can try to reproduce. Thanks!
Created attachment 9319 Exported panel config
(In reply to bpr_95 from comment #47) > Created attachment 9319 > Exported panel config This is how I reproduced the bug on a new panel. Note that compositing is disabled, but the Enter and Leave bars for Opacity in the Appearance menu are at 100 1. Add a new Panel, Panel 2 2. In Panel Preferences -> Appearance -> Configure, enable Compositing in the Window Tweaks menu that opens up NOTE: The Panel Preferences window closes, the debug log says that segfault occurred! Reopen Panel Preferences 3. Back in Panel Preferences ->Appearance, make Enter and Leave bars to 0 4. Now disable Compositing in Window Tweaks 5. Now add items to Panel 2 - say Power Manager and Notifications Area 6. Close the Panel Pref. menu, and kill xfce4-panel 7. Restart xfce4-panel, and for me, Panel 2 is blank To make the plugins on Panel 2 reappear, 1. Open Panel Preferences, go to Panel 2 2. In Panel Preferences -> Appearance -> Configure, enable Compositing in the Window Tweaks menu that opens up 3. Make Enter and Leave bars to 100 4. Disable Compositing 5. Plugins on Panel 2 should appear even after killing and restarting xfce4-panel I have attached the exported panel config also
Confirming. Affected icons of: Golden dict, claws-mail, KDE Connect, Pidgin, Pasystray, EasyStroke. So, that's all kde applicatons or applications which icon can show any status information. Can attach screenshot (if it can help somehow and if someone can explain me how to do it here) or resend it somethere or try to gather some information to debug. Fedora 30, xmonad, nvidia composition pipeline (without transparenty), xfce4-panel version 4.14.1.
Simon Steinbeiss referenced this bugreport in commit 536272e869ea5472a319a7368009f3b4f4051095 plugins: Fix enter/leave opacity w/o compositing (Bug #14577) https://git.xfce.org/xfce/xfce4-panel/commit?id=536272e869ea5472a319a7368009f3b4f4051095
Simon Steinbeiss referenced this bugreport in commit f6e855143571530b452ae40bc3b01a4fcb82256d plugins: Fix enter/leave opacity w/o compositing (Bug #14577) https://git.xfce.org/xfce/xfce4-panel/commit?id=f6e855143571530b452ae40bc3b01a4fcb82256d
@bpr_95: Thanks for the instructions, I was able to reproduce and fix the bug. While it was not directly related to the original bug discussed in this report, I linked the commits to this discussion for reference.