GNOME Bugzilla – Bug 773387
regression: gvim on gtk3 breaks due to recent gdkwindow change
Last modified: 2016-11-14 11:18:47 UTC
A recent gdkwindow commit on branch gtk-3-22 [1] breaks gvim 8 on gtk3 backend [2] for me. Output is: *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug Reverting [1] and a related cleanup [3] fixes the issue. [1] https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=12579fe71b3b8f79eb9c1b80e429443bcc437dd0 [2] 8.0.* from https://github.com/vim/vim [3] https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=6f7a6f769f1a8a7aa0214acc3d063940a33779c5
I can confirm this. My current guess is that this has something to do with GVIM's GtkForm container widget. https://github.com/vim/vim/blob/master/src/gui_gtk_f.c
I think I fixed this, see https://github.com/vim/vim/pull/1193 . I'll close the Arch Linux bug once I've made a gvim release, but I keep this one open so a gtk dev can decide whether this was indeed a gvim bug and not a gtk one.
Yes, this is an (unexpected) side effect of commit 12579fe0 And there is more to it, even with patching gvim as in https://github.com/vim/vim/pull/1193 there is still another issue because the drawarea in gvim also connects to the configure_event signal. But the widget GtkDrawingArea will emit a configure_event itself so what happens when swotching to tile or maximized is this: 1./ GtkDrawingArea emits a configure_event with the right (new) size on size_allocate: https://git.gnome.org/browse/gtk+/tree/gtk/gtkdrawingarea.c?h=gtk-3-22#n227 2./ Then call gdk_window_move_resize() which will send a configure_event based on the gdk *window* geometry - But at this point, the new layout from gtk is not propagated to gdk *yet* so the actual gdk window size is wrong 3./ The gvim drawarea receives the first confgure_event and resize accordingly 4./ gtk then processes the queued events, dequeing the configure events from configure_native_child() added in commit 12579fe0 and will resend a new configure_Event for the drawing ara butwith the *old* size. 3./ The gvim drawarea receives the second confgure_event and resize accordingly, but with the wrong size this time... So, I am in favor of reverting commit 12579fe0 and commit 6f7a6f7 *but* that will re-introduce the bug 771320 and bug 767713 and a bunch of other duplicates (some would even consider the totem fullscreen issue as a blocker) so I'd rather find another solution before reverting, but this is not an easy one (appeal of commit 12579fe0 was its simplicity...)
Oh blimey!... That's exactly the reason of the bug in clutter-gtk, the signal emit vs. the queued event... So I can fix bug 767713 in clutter-gtk instead and not touch gdk/gtk+! Fixing bug 771320 is another story though...
Can the changes that happened between 3.22.1 and .2 please be reverted again for .4? It doesn't seem great for a minor release to break something, especially if it's not just a fringe application.
The offending commits have been reverted and another fix for GtkStack pushed as a fix for bug 767713, this issue should be fixed in git branch gtk-3-22 now.