Rendering under macOS Mojave does not work until window is moved

[peterhellberg]

There seem to be a problem with glfw under macOS Mojave: glfw/glfw#1334
(unfortunately affects Pixel)

I compiled the examples for glfw and this is the result:

Before moving window

After moving window

The same behavior is seen for code using Pixel.

This issue might also affect Pixel: glfw/glfw#1337

[peterhellberg]

An ugly workaround for now is to move the window a single pixel on start, Eg. win.SetPos(win.GetPos().Add(pixel.V(0, 1)))

Or maybe something along these lines if you want to move the window back:

func mojaveWorkaround(win *pixelgl.Window) {
	pos := win.GetPos()

	win.SetPos(pixel.ZV)
	win.SetPos(pos)
}

[peterhellberg]

The reason for the workaround is to update the NSOpenGLContext (and there doesn't seem to be a direct way to do that)

[thegtproject]

I don't use Mac so bare with me, but couldn't you just syscall NSOpenGLContext?

[peterhellberg]

Yes, I meant something more along the line of “currently there isn't a direct way to do this from pixel, or go-gl/glfw”

This is the (deprecated) method that needs to be called: https://developer.apple.com/documentation/appkit/nsopenglcontext/1436135-update

In Objective-C this would have been something along these lines:

void
cocoa_update_nsgl_context(void* id) {
    NSOpenGLContext *ctx = id;
    [ctx update];
}

(copied from https://github.com/kovidgoyal/kitty/blob/b82e74f99ae30599cd88ef6a1216625b57a0414a/kitty/cocoa_window.m#L102-L106)

[faiface]

Well, this looks weird (isn't it just some bug in macOS?). But feel free to submit a PR to fix this. And, isn't there a nicer workaround? Like somehow updating the window or something?

[peterhellberg]

Yes, this is most likely a bug in macOS… but Apple is probably not going to fix something that they (very publicly) have deprecated. Hopefully this can be fixed directly in glfw 3.3

[peterhellberg]

The ugly workaround is just a way to trigger [ctx update] so to speak.

[diclophis]

@peterhellberg I can confirm a similar issue when using this library https://github.com/raysan5/raylib

[joshua-worby-madefire]

@peterhellberg I can confirm that we're seeing the same thing on our project for machines that have updated to MacOS 10.14. Any machine that's stayed on MacOS 10.13.6 work fine.

Also, moving the window does get the rendering to work again.

[martinlindhe]

Just adding some (possibly irrelevant) notes to the issue.

SDL2 <= 2.0.8 has a similar issue in Mojave. It has been resolved in the recently released SDL 2.0.9

Here is more info on their issue: https://discourse.libsdl.org/t/macos-10-14-mojave-issues/25060

[Lallassu]

I've also experienced this issue. I've use a workaround by centring the window on the screen. This code was found in some of the pixel examples.

    func CenterWindow(win *pixelgl.Window) {
	x, y := pixelgl.PrimaryMonitor().Size()
	width, height := win.Bounds().Size().XY()
	win.SetPos(
		pixel.V(
			x/2-width/2,
			y/2-height/2,
		),
	)
    }

[peterhellberg]

Yes, moving the window (any number of pixels) is a workaround for now.

[delp]

@peterhellberg @Lallassu @martinlindhe Anyone want to look at this again now that we are on GLFW 3.3?

[martinlindhe]

I think this issue has been resolved for some time by updates to SDL, GLFW and other affected apps.

[peterhellberg]

I tried to reproduce the problem but was unable to do so.