Widgets not rendering following a resize
https://gitlab.com/inkscape/inkscape/issues/125
Steps to reproduce
- Build Inkscape or download a pre-built appimage
- start it, change the size of the window, (restart Inkscape,) change the tool to e.g. the rect, node, or text tool
- 2019-07-03_19-44-47
Current behavior
on wayland the toolbar remains empty
on x11 it works
Expected outcome
Works reliably
Version information
- 3.24.8-1ubuntu1 (in the appimage)
- 3.24.9-1.fc30 (when compiled on fedora)
Additional information
-
these toolbars are handled by a GtkStack and updated with gtk_stack_set_visible_child_name, but the issue is deeper than that because it used to be a GtkContainer with a gtk_widget_hide+gtk_widget_show_now and the same problem happened (the change was made in order to have something more gtk-esque and clean in the hope it would fix stuff), in src/widgets/toolbox.cpp:update_aux_toolbox )
-
only appears on Wayland, for some reason (fc30 with xorg works)
-
I did get any breakpoint on _cairo_error when trying stuff but got a non-reproduced crash on _gdk_wayland_display_queue_events
-
IRC log
19:52 < Mc> Hi ! Do you have an idea what can make a widget appear empty when it's shown, and only show up upon modification ? https://marc.jeanmougin.fr/share/2019-07-03_19-44-47.mov / https://gitlab.com/inkscape/inkscape/issues/125
19:52 < gitlab-bot> Inkscape issue 125 in inkscape "Toolbar empty after startup" [Importance::High, Ui, Opened]
19:53 < Mc> it happens reliably when reopening the application after having resized it, and unreliably without that
19:53 < Mc> also, only on fedora and not on debian/ubuntu
19:59 <@Company> Mc: rendering failures (ie the cairo_t or some cairo_surface_t being set into an error state)
19:59 <@Company> Mc: mismatches of cairo_save() and cairo_restore() (or push_group() and pop_group())
20:00 < Mc> is there a way to check that ?
20:01 <@Company> GTK tries to catch the errors and g_warning()s when it detects it, but if there's redirections or so going on (I have no idea how sophisiticated those toolbars are), it might go past
20:01 <@Company> save/restore mismatches I have no idea - I flat out don't remember how I debugged those issues
20:01 < Mc> it's basically a bit gtkstack with a lot of widgets[1~[4~
20:02 <@Company> errors are trackable by setting a breakpoint on _cairo_error
20:02 <@Company> and investigating when it triggers (though it can trigger for legitimate reasons, too)
20:04 <@Company> it could also be that somebody computes a clip wrong and then optimizes away or cairo_clip()s the rendering in some special situations, but I don't think GTK itself does that
20:04 <@Company> and of course, there can always be bugs inside cairo
20:07 <@Company> i guess the first question to answer is "is the toolbar's draw function called or not?"
20:07 < Mc> I call show_all()
20:10 <@Company> the question is more meant as "does the bug happen before the toolbar is (not?) drawn or after"
20:24 < Mc> can this be a wayland vs xorg problem ?
20:31 < Mc> I do have a bp on _cairo_error and it's apparently never reached
20:32 < Mc> (file cairo-error.c, line 66.)
20:49 < Mc> also with the GTK_DEBUG=interactive thing as soon as I alt-tab to it to see what's in the empty bar, it appears ><
- using GTK_DEBUG=interactive does not help as the toolbar appears as soon as the focus is given to the debug window ^^
Edited by Ghost User