In `Window Buttons` xfce4-panel plugin, in its settings there's `Show flat buttons` option, if this is NOT selected, then the CPU usage(for both Xorg process and xfce4-panel) is unusually high(say 25-39% for each, for 1 core of CPU set to max 800Mhz) depending on how many buttons are currently present, especially visible when painting of buttons happens such as when `Visual bell` of xfce4-terminal is in effect and thus (at least) one button is blinking(too). Or, when switching tasks by clicking on the window, even if the panel is hidden (and thus the `Window buttons` are not visible) . Selecting `Show flat buttons` reduces CPU usage for Xorg to about 7% (at worst) on a CPU limited to 800Mhz seen via `top -d 2` (ie. 2 seconds refresh), and about 5.9% CPU is the usual Xorg CPU usage. At best, no CPU usage difference is detected between when a window blinks and when it doesn't. tested xfce4-panel 4.14pre2.r39.g5a497c25-1 commit 5a497c257fd9e035133fd9e89fc91079c9fb5fc8 (HEAD -> makepkg, origin/master, origin/HEAD) Date: Thu Jul 18 06:30:45 2019 +0200 The only reason I was able to find this if because sometimes when xfce4-terminal `Visual bell` is in effect and thus blinks the entire window title, its respective button of `Window Buttons` does not blink(it should but it doesn't sometimes) and thus no CPU usage increase is seen! This must be another small bug, but thanks to it, I was able to track this one down!
Note: my build already has had this commit present, which was mentioned in another bug that fixed some _similar_ issue for others: https://bugzilla.xfce.org/show_bug.cgi?id=13829#c12
Interesting, this might be a bug in gtk after all? given my superficial understanding of things: (I wonder how I could test this ... maybe I could modify a gtk3 example somehow?) so GTK_RELIEF_NORMAL is non-flat buttons ```c case PROP_FLAT_BUTTONS: xfce_tasklist_set_button_relief (tasklist, g_value_get_boolean (value) ? GTK_RELIEF_NONE : GTK_RELIEF_NORMAL); break; ... static void xfce_tasklist_set_button_relief (XfceTasklist *tasklist, GtkReliefStyle button_relief) { GList *li; XfceTasklistChild *child; panel_return_if_fail (XFCE_IS_TASKLIST (tasklist)); if (tasklist->button_relief != button_relief) { tasklist->button_relief = button_relief; /* change the relief of all buttons in the list */ for (li = tasklist->windows; li != NULL; li = li->next) { child = li->data; gtk_button_set_relief (GTK_BUTTON (child->button), button_relief); } /* arrow button for overflow menu */ gtk_button_set_relief (GTK_BUTTON (tasklist->arrow_button), button_relief); } } ``` https://developer.gnome.org/gtk3/stable/GtkButton.html#gtk-button-set-relief The default style is, as one can guess, GTK_RELIEF_NORMAL.
well I applied this gtk3 patch so that all relief buttons everywhere are actually flat (which now means `Show flat buttons` has no effect and acts like it's always on): ```diff diff --git a/gtk/gtkbutton.c b/gtk/gtkbutton.c index 26b7ffba38..31fd115557 100644 --- a/gtk/gtkbutton.c +++ b/gtk/gtkbutton.c @@ -1597,10 +1597,10 @@ gtk_button_set_relief (GtkButton *button, if (old_relief != relief) { context = gtk_widget_get_style_context (GTK_WIDGET (button)); - if (relief == GTK_RELIEF_NONE) + //if (relief == GTK_RELIEF_NONE) gtk_style_context_add_class (context, GTK_STYLE_CLASS_FLAT); - else - gtk_style_context_remove_class (context, GTK_STYLE_CLASS_FLAT); +// else +// gtk_style_context_remove_class (context, GTK_STYLE_CLASS_FLAT); g_object_notify_by_pspec (G_OBJECT (button), props[PROP_RELIEF]); } ``` I can't tell if it's gtk3 issue or not, assuming it is unless xfce4-panel uses https://developer.gnome.org/gtk3/stable/GtkButton.html#gtk-button-get-relief and does something with the returned value which doesn't seem like it, except in this irrelevant case: ``` #if !GTK_CHECK_VERSION (3, 0, 0) /* store the relief of the button */ button->priv->last_relief = gtk_button_get_relief (GTK_BUTTON (button)); #endif ``` file: `xfce4-panel/libxfce4panel/xfce-arrow-button.c` I'll try open a gtk3 issue
https://gitlab.gnome.org/GNOME/gtk/issues/2041
The upstream bug is closed and you said you were happy with the workaround, is there anything to fix on Xfce side?
> is there anything to fix on Xfce side? Nothing at all. Please close. Thanks!