GNOME Bugzilla – Bug 751140
lots of "pixman_region32_init_rect: Invalid rectangle passed"
Last modified: 2015-06-22 13:27:23 UTC
Bisected to https://git.gnome.org/browse/gtk+/commit/?id=c5e5ee67490e7e7 ############# #include <gtk/gtk.h> int main (int argc, char **argv) { GtkWidget *window, *button; gtk_init (&argc, &argv); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); button = gtk_button_new (); gtk_container_add (GTK_CONTAINER (window), button); gtk_widget_show_all (window); return 0; } ############# * BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug
(since it was asked in IRC) I'm using gnome-shell 3.16.2
Can reproduce, but considering that the code example does not deal with client-side decorations, I strongly doubt my commit is related — except as it probably exposes a logic bug that was masked before.
The backtrace, for the record:
+ Trace 235185
$1 = {x = 46, y = 23, width = -40, height = 10} I suspect we're still trying to remove something from the allocation even if CSD is not used.
So, this is odd: - return csd_env == NULL || (strcmp (csd_env, "1") == 0); + return (g_strcmp0 (csd_env, "1") == 0); This change to gtk_window_can_use_csd() fixes the issue — in the sense that we don't get invalid rectangles — but I'm a bit at loss as to why. g_strcmp0() returns `-(str1 != str2)` if str1 is NULL, because it can be used for sorting, and NULL strings come before non-NULL ones. In this case, we're doing a strict equality, so the two lines above have the same truth value.
The issue is that before we were returning FALSE is GTK_CSD was unset, which is not really what we want. The commit in question changed the logic to return TRUE from can_use_csd() if GTK_CSD is unset — which breaks some state down the line. Fun.
Created attachment 305582 [details] [review] window: Reinstate logic for should_use_csd() The old should_use_csd() function would return FALSE if the GTK_CSD environment variable is unset; the change in commit c5e5ee67490e7e7 made it return TRUE if GTK_CSD is unset. This has a cascade effect on the window size, which causes invalid rectangles to bubble down to Pixman.
Attachment 305582 [details] pushed as f043fd5 - window: Reinstate logic for should_use_csd()
And this, obviously, broke CSD because now can_use_csd(), which is used by enable_csd(), returns FALSE when GTK_CSD is unset. I guess the proper solution is to actually find out *where* we're screwing up the size of the GdkWindow, thus causing invalid rectangles to be submitted to Pixman.
Created attachment 305739 [details] [review] Fix calculation of edge input window size in case the real window is too small. This error resulted in warnings like "pixman_region32_init_rect: Invalid rectangle passed" In case the window is smaller than handle_size * 2 the resulting edge window got a negative size. Prevent that by limiting the handle size to half the respective edge length. This also prevents the corner windows from overlapping in case the window is too small.
Side note: this doesn't handle cases where the calculation results in a zero width/height input window, which gdk silently fixes to be 1 pixel width/height windows in gdk_window_move_resize_internal(). The previous code didn't either so I left it that way.
Review of attachment 305739 [details] [review]: Looks good. I've reverted commit c5e5ee6 because it broke the default size of empty GtkWindows, but this patch catches invalid sizes before we get to Cairo, which is a good thing.