Blank window on macOS 10.14

[wizardfrag]

Hi,

I've installed kitty using the bash script, however once it started it presented me with a blank window as below:

Interacting with the terminal (such as by typing say Hello world) works, however nothing is output to the screen. I'm not sure if this is an issue with kitty or with macOS 10.14, but it would be nice to use this!

Required info

kitty version: 0.12.0
macOS version: 10.14 Beta (18A384a)
kitty config: default as installed by bash script

[kovidgoyal]

sorry, I dont have the resources to support beta OSes. I can tell you that kitty works fine with 10.13.

Make sure that the text is not just invisible because the foreground color is the same as the background color. (You can drag witht he mouse to selelct which should test that).

[wizardfrag]

That's fine, I understand that.

Is there any way I can try to debug this myself?

[kovidgoyal]

As I said, the first step is to check if it si a color problem. Assuming it isn't run kitty from the command like with the --debug-gl flag and see if it reports any errors. Also check console.app for any error messages.

[wizardfrag]

Ah I thought I'd mentioned that I tried selecting text... --debug-gl doesn't show anything, however moving/resizing the window around causes it to start rendering... I'll close this for now...

[kovidgoyal]

See if the following patch helps:

diff --git a/kitty/child-monitor.c b/kitty/child-monitor.c
index 063baa0a..6a0b7bb1 100644
--- a/kitty/child-monitor.c
+++ b/kitty/child-monitor.c
@@ -769,6 +769,12 @@ static PyObject*
 main_loop(ChildMonitor *self, PyObject *a UNUSED) {
 #define main_loop_doc "The main thread loop"
     bool has_open_windows = true;
+#ifdef __APPLE__
+    if (global_state.has_pending_resizes) process_pending_resizes(now);
+    render(now);
+    wakeup_main_loop();
+    wait_for_events();
+#endif
 
     while (has_open_windows) {
         double now = monotonic();

[nthapaliya]

I tried the patch. It doesn't compile.

[wizardfrag]

I've gotten it to compile by adding double now = monotonic() after the #ifdef and compiling using CFLAGS=-Wno-error make however it still doesn't seem to render...

Without the CFLAGS it complains that a lot of the calls from glfw are deprecated... I can provide logs if necessary?

[kovidgoyal]

Well that was just a shot in the dark. Apple has deprecated OpenGL so that's not a surprise.

[kovidgoyal]

Well now that mojave has been released officially, I am re-opening. Sadly I wont have access o my mac for another day or two, so I dont know if the issue is still present.

[zackangelo]

Can confirm that the issue is still present in the Mojave GA release.

[wy15]

The issue is still present in the release.

[kovidgoyal]

Well, I will look into figuring out what apple broke in a few days when I have access to my mac again

[wy15]

[kovidgoyal]

In the meantime, for anybody that wants to experiment themselves, since we know that a resize causes rendering to start behaving normally, you just need to see what happens in the resize code path and do that once at startup. The relevant functions are framebuffer_size_callback and update_os_window_viewport

[erf]

it seem to work as normal if background_opacity is set to less than 1.

[net]

Possibly related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31904

[d53dave]

it seem to work as normal if background_opacity is set to less than 1.

I have just tried this but it didn't fix the issue for me.

Also possibly related: if I try to start it from the command line, I get the following error twice:

[269 12:19:21.314076] [PARSE ERROR] Unknown OSC code: 7

[kovidgoyal]

An update. Either moving or resizing the window will cause it to draw. I looked into what happens on a move and basically commenting out the line:

[window->context.nsgl.object update]

in windowDidMove causes moving to not cause correct rendering. So obviously we now need to call update ont he context object. The problem is I am not sure where is a good place to do that. Doing it in the constructor or the call to showwindow does not work. So I suppose it will simply have to be called once per window on first render. Which will need a new native call api in glfw, sigh.

[jameswritescode]

Will there be a release with this fix soon / documented way to generate a new dmg from source?

[kovidgoyal]

there already is a documented way to build the app from source https://sw.kovidgoyal.net/kitty/build.html

[kovidgoyal]

https://sw.kovidgoyal.net/kitty/faq.html#how-do-i-build-kitty-app-on-macos

[jameswritescode]

Thanks!

[kovidgoyal]

changing the NSView into a layer backed view is likely to have performance implications or other side-effects, seem safer to just call NSOpenGLContext update a couple of times at startup.

[elnormous]

Yes, I agree. I did some more debugging and disassembling and came to a solution. I posted the results here: https://stackoverflow.com/questions/52938516/opengl-not-rendering-on-macos-mojave/52938517#52938517
Basically, you have to update the NSOpenGLContext in NSView's setLayer: method because OpenGL is rendered in a layer on Mojave even if you explicitly disable it by setting wantsLayer to NO.
Here is my commit to the Ouzel engine: elnormous/ouzel@7e70863

[kovidgoyal]

yeah that works well

[Tagar]

I have similar issue not only on macOS, but on Windows as well.
Blank screen first, and when window is resized, it renders fine again.

[Luflosi]

kitty does not run on Windows. I think you're talking about a different project, possibly KiTTY.

[Tagar]

@Luflosi you're right, created cyd01/KiTTY#67 instead
sorry for the confusion