>> Because the frame has to resize _and_ move. GTK has an internal >> function that moves and resizes a window in one go but I haven't seen an >> external interface to it. > > But I can drag it smoothly (by the mode-line), and I can resize it smoothly. It kind of weird that drag+resize is more than 2x as slow. It's not only weird. IIUC it's also wrong sometimes. I guess parts of Emacs' readjust-positions code get into the way here. > Does building with '-Og' help? It's really fast here, faster than GTK by an order of magnitude (or two). I haven't tried it. What I need is an executable I can debug reliably. >> Next thing to try: Before the >> >> gtk_window_get_size (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), >> &gwidth, &gheight); >> >> lines in xg_frame_set_char_size insert the two lines >> >> if (!gtk_window_get_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)))) >> gtk_window_set_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), TRUE); >> >> put a breakpoint on the second one and tell me whether you get a hit. >> Just to make sure ... > > Still no luck (hits line 960, but not 961). So at least no-one interferes with this. Next thing to try is to always run XResizeWindow and XMoveWindow for GTK child windows. This should avoid any GTK related checks for them. The attached patch has three hunks. Try them all first and maybe try to only apply the last one (or the last two) afterwards. Here it breaks my "moving the left or top border of GTK child frames" behavior. martin