GNOME Bugzilla – Bug 81630
gtk_fixed_move is incredibly slow
Last modified: 2018-05-02 13:39:37 UTC
I have a screensized window (desktop background) with a GtkFixed containing all the icons. When the icons are repositioned by dragging them, the redraw is really slow (about 1 update per second). This seems to be because gtk_fixed_move keeps trying to resize the widget (even though it's a fixed size) and this causes Gtk to redraw the whole thing. Using my own version of gtk_fixed_move, which doesn't try to resize, I can get totally smooth motion. I think GtkFixed should not try to resize unless it actually needs to (add and remove operations are also noticably slow).
You could probably make a patch to improve GtkFixed by figuring out the area that needed to be redrawn, invalidating that yourself, and queueing the resize on the child rather than the parent.
Created attachment 92485 [details] [review] Proposed patch to fix the problem After some revisions and talk to some people in Guadec I've finished a first proposal of the patch that tries to improve the performance of the removal and the movement of the widgets inside the fixed objects. There are two new functions (gtk_fixed_child_invalidate, gtk_fixed_child_allocate), that I've created just to avoid code duplication in the file. I've tested and it avoids the size_request when it is not required because the movement of the internal widgets does not cause a change in the fixed requisition. It adds the same control to the movement and to the removal operations. Hope it helps, waiting for comments :-).
Created attachment 92487 [details] Crappy testing program This is small example that can be used to check the movement and the removal of the widgets inside the gtkfixed. You can use this example and activate debug options in gtk to check what's going on when you change the widgets.
I think that it is the simplest solution fot this problem to call gtk_widget_queue_resize not for GtkFixed itself but for its child widget in gtk_fixed_move_internal as the GtkLayout does in gtk_layout_move_internal. This is a bug of gtkfixed.c.
I can't believe this bug is that old and not fixed yet. I connect to gtk_fixed's size-allocate signal and there I resize AND move my widgets around. That results in more size-allocate signals being emitted and my program enters an infinite loop. After some testing I concluded that _move() operations emit these signals. So is there any will to fix this soon? I think this bug basically renders GtkFixed useless.
Created attachment 148498 [details] [review] Almost the same patch as bug #68263 GtkLayout had had almost the same problem and it has been fixed, I think. See bug #68263.
@INAGAKI your patch looks interestig. I would like to patch gtkfixed and test it. Is there an easy way to do it? I would like to use the patched version of gtkfixed in my program(and include the code) and use everything else from the gtk-libs my OS provides(Ubuntu). Is that possible? If yes, how do I instruct the compiler/linker to make the distinction? I am little baffled that this is marked as "enhancement" and low priority. This is a show-stopper for those you want to do manual resizing and not rely on Vbox/Hbox
I'm curious whether this is still "incredibly slow" for anyone in practical situations with today's hardware. Anyway, Bug 68263 seems interesting in relation to this; it may be worth someone testing that. I see no indication in Comment 6 that any real testing was done, however, and the patch would need updated to apply today. (In reply to Hammered from comment #7) > @INAGAKI your patch looks interestig. I would like to patch gtkfixed and > test it. Is there an easy way to do it? JHbuild > I would like to use the patched > version of gtkfixed in my program(and include the code) and use everything > else from the gtk-libs my OS provides(Ubuntu). Is that possible? If yes, how > do I instruct the compiler/linker to make the distinction? No. You can use LD_LIBRARY_PATH to make the loader prefer libraries in specific paths over its defaults, but you can't pick and choose which widgets are loaded from which version of the lib.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/219.