[gimp] app: don't propagate resize requests from statusbar to display shell.

[Jehan <jehanp src gnome org>]

commit 32049afd054c2846ef667d427e625cb53ebd5277
Author: Jehan <jehan girinstud io>
Date:   Sun Feb 13 12:55:52 2022 +0100

    app: don't propagate resize requests from statusbar to display shell.
    
    See discussion in !572, #7840 and #7690. Note that this was reported on
    macOS where the consequences were pretty dire, but it actually also
    happens on other platforms, at least on Linux too (as confirmed in X11
    with the GTK Inspector set to show graphics updates; on Wayland this
    debug option doesn't work, but I assume it is the same).
    
    I am not perfectly happy with this change either, because it is based on
    part of the API which has various deprecated parts (hence doesn't exist
    anymore on the main dev tree, i.e. it might have to be reviewed in GTK4;
    of course, it's unsure, maybe the whole resize propagation to parent
    containers is just better handled there and the problem won't exist
    anymore).
    In any case, it is cleaner than the proposition for this part of the
    problem in !572 which is problematic (patching GtkLabel with a new API
    which won't trigger resize even when actually needed, hence which likely
    won't ever get accepted upstream because it's not right).

 app/display/gimpstatusbar.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
---
diff --git a/app/display/gimpstatusbar.c b/app/display/gimpstatusbar.c
index 052f58d32d..a6b16b158e 100644
--- a/app/display/gimpstatusbar.c
+++ b/app/display/gimpstatusbar.c
@@ -203,6 +203,31 @@ gimp_statusbar_init (GimpStatusbar *statusbar)
   gtk_container_add (GTK_CONTAINER (statusbar), hbox);
   gtk_widget_show (hbox);
 
+  /* When changing the text of the cursor_label, it requests a resize
+   * bubbling up to containers, up to the display shell. If the resizing
+   * actually happens (even when the size is the same), a full "draw"
+   * signal is triggered on the whole canvas, which is not a good thing
+   * as a general rule (and very bad on some platforms such as macOS).
+   * It's too late to do anything when processing the "draw" signal
+   * because then we can't know if some part of the invalidated
+   * rectangle really needs to be redrawn. What we do is not propagate
+   * the size request back to container parents. Instead we queue the
+   * resize directly on the widget.
+   *
+   * Note that the "resize-mode" property seems to be unrecommended now
+   * (though only the public functions are deprecated, we get no
+   * deprecation setting as a property) but it's still here in GTK3 and
+   * still seems like the proper way to avoid propagating useless
+   * no-actual-size-change resizes to container widgets.
+   * XXX On GTK4, we will likely have to test again and if it's still a
+   * problem, make a different fix.
+   *
+   * See discussion in MR !572.
+   */
+  g_object_set (statusbar,
+                "resize-mode", GTK_RESIZE_QUEUE,
+                NULL);
+
   statusbar->shell          = NULL;
   statusbar->messages       = NULL;
   statusbar->context_ids    = g_hash_table_new_full (g_str_hash, g_str_equal,