blank black window about kitty HOT 23 CLOSED

Run it ina terminal and see if there are any error messages being output

from kitty.

I might be getting the same problem, when running python3 . from the clone directory, a blank black window appears (I'm using Debian testing).

However, when I maximize the window, I see something displaying, namely a small red field. After resizing the window back to the regular size, I get correct display.

Here's how the kitty window looks like after maximixing it:

And after resizing back to the regular size:

Seems that if the window resize callback gets called twice, the display starts working properly.

from kitty.

There is no error message when I run it from command line.

When I maximize, I see the prompt, and then when I return to the original size, I see the prompt.

from kitty.

Might be a timing issue with the launch of the child process (bash) and the first resize of the window. You can test that by inserting the following two lines at line 62 of child.py

import time
time.sleep(2)

Remember to maintain correct indentation.

This will cause kitty to wait a couple of seconds before running the child process

from kitty.

is that before or after the "try:"?

from kitty.

Just tried, but I still see the same issue.

What's interesting, even in the blank-screen state, the terminal works (although I can't see my prompt or my keypresses being echoed out). When I blindly type in touch /tmp/foo and then close kitty, I see the file appear in /tmp anyway, even though the kitty screen is all black the whole time.

This suggests the bash process is running and it's a render issue.

from kitty.

That seems like problem with the renderer ajusting the OpenGL render size, can't check now because mine won't build but make sure that the render aspect ratio is correctly set, as this seems to be an issue that occurs on some graphics hardware, as the system is a bit slow at sending resize events.

from kitty.

Ah, I just ran a different experiment, simulating the resizing the window twice by adding this to boss.py

diff --git a/kitty/boss.py b/kitty/boss.py
index 310d268..c757b7e 100644
--- a/kitty/boss.py
+++ b/kitty/boss.py
@@ -105,6 +105,11 @@ class Boss(Thread):
         self.glfw_window.set_click_cursor(False)
         self.show_mouse_cursor()
         self.start_cursor_blink()
+        import time
+        time.sleep(2)
+        self.on_window_resize(self.glfw_window, 60, 60)
+        time.sleep(2)
+        self.on_window_resize(self.glfw_window, 320, 320)
 
     def signal_received(self):
         try:

After running I get a few seconds of blank screen and then the prompt appears.

from kitty.

@wulczer you should probably move import time to the start, python runs imports before everything else if they aren't in a class for function. What you are doing makes it so that the import doesn't happen untile the class is parsed, which isn't great for performance.

from kitty.

That was just an experiment, I'm not concerned with performance (and it's not an acceptable fix anyhow, it's just a clue about where the real problem might lie).

from kitty.

@wulczer Right. Pretty much confirms what I was saying though, with the resize call running late.

from kitty.

Is this wayland or X11. My X11 seems to be going fine.

from kitty.

Do you actually need two resizes or does one suffice? I'm guessing the problem is that apply_pending_resize() is not being called, which will cause render() to not do anything since rendering is disabled until at least one resize occurs. Can your stick a couple of print statements into on_window_resize() and apply_pending_resize() to see if theya re ever being called?

from kitty.

@kovidgoyal A quick fix which works for me is just to wait for the last resize event before calling the resize function. A bit dirty, but it works.

from kitty.

@geordieF Sorry I'm not sure I understand what you're asying exactly, a git diff would help :)

from kitty.

@kovidgoyal you're right, a single resize is enough. I ran with this:

diff --git a/kitty/boss.py b/kitty/boss.py
index 310d268..4edd17c 100644
--- a/kitty/boss.py
+++ b/kitty/boss.py
@@ -105,6 +105,9 @@ class Boss(Thread):
         self.glfw_window.set_click_cursor(False)
         self.show_mouse_cursor()
         self.start_cursor_blink()
+        # import time
+        # time.sleep(2)
+        # self.on_window_resize(self.glfw_window, 320, 320)
 
     def signal_received(self):
         try:
@@ -215,12 +218,15 @@ class Boss(Thread):
 
     @callback
     def on_window_resize(self, window, w, h):
+        print('on window resize')
         # debounce resize events
         self.pending_resize = True
         yield
+        print('scheduling applying the resize')
         self.timers.add(0.02, self.apply_pending_resize, w, h)
 
     def apply_pending_resize(self, w, h):
+        print('applying the resize')
         viewport_size.width, viewport_size.height = w, h
         self.tab_manager.resize()
         self.resize_gl_viewport = True

With the sleep and resize commented out and no user input, I get no prints and no prompt, the window is stuck in blank mode.

With the sleep and resize uncommented, I get

on window resize
scheduling applying the resize
applying the resize

And the prompt appears without any additional intervention.

@geordieF Polish, actually :)

from kitty.

Actually, this fixes the problem on its own for me:

diff --git a/kitty/boss.py b/kitty/boss.py
index 310d268..c31d14e 100644
--- a/kitty/boss.py
+++ b/kitty/boss.py
@@ -72,7 +72,7 @@ class Boss(Thread):
         self.cursor_blinking = True
         self.glfw_window_title = None
         self.action_queue = Queue()
-        self.pending_resize = True
+        self.pending_resize = False
         self.resize_gl_viewport = False
         self.shutting_down = False
         self.screen_update_delay = opts.repaint_delay / 1000.0

from kitty.

Should i do a PR for this, or will kovid do it

from kitty.

Yes, the issue seems to be that there is no initial resize event on your systems. I'll have to think a little bit about whether allowing rendering without an initial resize is acceptable or will it have any other side-effects. If not then I will commit that change.

from kitty.

This might be relevant: glfw/glfw#62

from kitty.

After reading that bug, wait for the last resize and then wait about a ms for the change to occur, it's a bit hacky, but actually improves performance

from kitty.

Resizes are already debounced, the problem is that there is no resize event at all unless the user resizes the windows, and currently kitty assumes there will be at least one resize. After staring at the code for a bit I cant see any problems with allowing rendering with no resize (there might be a bit of flicker at the startup, is the worst I could find). So I am commit this change. Fingers crossed :)

from kitty.

Thanks!

from kitty.