Rendering issue after resize

[TJohnW]

I noticed some strange behavior if Kitty is resized while it doesn't have focus. The sizes at which this occur are seemingly random 😕, but it happens consistently while resizing smaller and on the left side of the screen.

I'm running from master and on OSX 10.13.4

Also, the program I am using to resize is the window manager https://github.com/koekeishiya/chunkwm

[kovidgoyal]

I cannot reproduce (albeit on linux, though the window refresh code is the same), does this happen if you run kitty with the default config?

kitty --config NONE

And @koekeishiya might be interested since it involves chunkwm

[TJohnW]

Default config is the same. I also tried on a different laptop running OSX 10.12 and recreated the problem using Hammerspoon instead of chunkwm to resize kitty while it didn't have focus.

Hammerspoon script used:

hs.hotkey.bind({"cmd", "alt", "ctrl"}, "R", function()
  hs.grid.resizeWindowThinner(hs.appfinder.windowFromWindowTitle("kitty"))
end)

[TJohnW]

I looked into it a little, these quick changes changes seem to fix it for me locally. Not entirely sure whats going on but from a quick glance: it seems like the glfw wait timeout is being set to -1 when focus is lost. Then the resize flags / RESIZE_DEBOUNCE_TIME is effectively ignored.

[kovidgoyal]

Hmm that does not really make sense. The resize callback is called on the same thread as the main loop. So the main loop must tick at least once after a resize event. And the timeout is adjusted based on the debounce time in the main loop. See main_loop() in child-monitor.c.

[kovidgoyal]

I installed hammersppon on my mac and was unable to replicate with it.

[kovidgoyal]

See if this fixes it. I cannot reproduce, so I cannot test

diff --git a/kitty/child-monitor.c b/kitty/child-monitor.c
index a43bd542..9a2a1f89 100644
--- a/kitty/child-monitor.c
+++ b/kitty/child-monitor.c
@@ -726,8 +726,10 @@ process_pending_resizes(double now) {
     for (size_t i = 0; i < global_state.num_os_windows; i++) {
         OSWindow *w = global_state.os_windows + i;
         if (w->has_pending_resizes) {
-            if (now - w->last_resize_event_at >= RESIZE_DEBOUNCE_TIME) update_os_window_viewport(w, true);
-            else {
+            if (now - w->last_resize_event_at >= RESIZE_DEBOUNCE_TIME) {
+                update_os_window_viewport(w, true);
+                set_maximum_wait(0);
+            } else {
                 global_state.has_pending_resizes = true;
                 set_maximum_wait(RESIZE_DEBOUNCE_TIME - now + w->last_resize_event_at);
             }

[TJohnW]

I just tried and that doesn't resolve it for me. If you monitor the maximum wait when kitty loses focus do you ever get -1? Whenever kitty loses focus on my end, the wait timeout is set to -1 and the main loop doesn't run while kitty is in the background. I can verify that framebuffer_size_callback is still being called while resized and out of focus, but it's not causing the main loop to tick for some reason.

[kovidgoyal]

That would imply there's a bug in glfw, the main loop is definitely supposed to tick when events are delivered, the resize event being one type of event. You can test that by looking in glfw/cocoa_window.m

See the function _glfwPlatformWaitEvents(void)

This si what is called when there is a timeout of -1. See if that is indeed where it is hanging.

Also, see if this commit helps: 612fb3b

[kovidgoyal]

Oh and to answer your question, yes I do see a timeout of -1 when kitty is unfocused. But the main_loop wakes up for me when I trigger the hammerspoon resize event.

[kovidgoyal]

See rust-windowing/winit#219 (comment) and https://stackoverflow.com/questions/30410998/cocoa-event-loop-blocks-while-tracking-a-menu

apparently cocoa sometimes spins up sub-loops in sendEvent, which can prevent it from returning. That is presumably what is happening in your case. I have no idea why it happens for you only. Presumably some systemwide setting/addon?

Anyway I dont see any way to fix this. Cocoa and glfw have fundamentally mismatched APIs. glfw expects to be able to poll for events and return. cocoa expects to be in control of the event loop.

[kovidgoyal]

Since posting an empty event in the resize callback seems to cause the sub-loop to quit for you, I suppose we can use that as a hacky work-around.

[TJohnW]

Okay cool, that fix works fine for me on both laptops. Thanks for the help 👍