examples/windowsize: pressing N to minimizes causes app to freeze

[TotallyGamerJet]

Ebitengine Version

@d15b12b4

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

go version go1.22.1 darwin/arm64

What steps will reproduce the problem?

Press 'N' after running examples/windowsize

What is the expected result?

To minimize but still be runnable.

What happens instead?

The app freezes and becomes unresponsive even after returning focus.

Anything else you feel useful to add?

No response

[hajimehoshi]

The app freezes and becomes unresponsive even after returning focus.

It depends. You have to call SetRunnableOnUnfocused(false).

[TotallyGamerJet]

The app freezes and becomes unresponsive even after returning focus.

It depends. You have to call SetRunnableOnUnfocused(false).

Pressing N minimizes the window. When I click on it again the app is no longer running and I cannot close it nor do any other action. I have to force quit it.

[hajimehoshi]

Oh? I'll try

[hajimehoshi]

I failed to reproduce this.

                    'c.          [email protected] 
                 ,xNMM.          ------------------------------------- 
               .OMMMMo           OS: macOS 14.2.1 23C71 arm64 
               OMMM0,            Host: Mac15,6 
     .;loddo:' loolloddol;.      Kernel: 23.2.0 
   cKMMMMMMMMMMNWMMMMMMMMMM0:    Uptime: 59 days, 42 mins 
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.    Packages: 77 (brew) 
 XMMMMMMMMMMMMMMMMMMMMMMMX.      Shell: zsh 5.9 
;MMMMMMMMMMMMMMMMMMMMMMMM:       Resolution: 1800x1169 
:MMMMMMMMMMMMMMMMMMMMMMMM:       DE: Aqua 
.MMMMMMMMMMMMMMMMMMMMMMMMX.      WM: Quartz Compositor 
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.    WM Theme: Blue (Light) 
 .XMMMMMMMMMMMMMMMMMMMMMMMMMMk   Terminal: tmux 
  .XMMMMMMMMMMMMMMMMMMMMMMMMK.   CPU: Apple M3 Pro 
    kMMMMMMMMMMMMMMMMMMMMMMd     GPU: Apple M3 Pro 
     ;KMMMMMMMWXXWMMMMMMMk.      Memory: 3500MiB / 18432MiB 
       .cooc,.    .,coo:.

% go version
go version go1.22.1 darwin/arm64

[TotallyGamerJet]

I'm not sure why you can't reproduce it. I've cleared Go's cache, updated macOS since there were some Xcode changes and it still happens every time.

[hajimehoshi]

What is your macOS version?

[TotallyGamerJet]

Version 14.4 (23E214)

[hajimehoshi]

I'll try to update. macOS14.4 seems notorious

https://news.ycombinator.com/item?id=39741115

[hajimehoshi]

I failed to reproduce this 14.4 and the example still worked as expected:

                    'c.          [email protected] 
                 ,xNMM.          ------------------------------------- 
               .OMMMMo           OS: macOS 14.4 23E214 arm64 
               OMMM0,            Host: Mac15,6 
     .;loddo:' loolloddol;.      Kernel: 23.4.0 
   cKMMMMMMMMMMNWMMMMMMMMMM0:    Uptime: 3 mins 
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.    Packages: 77 (brew) 
 XMMMMMMMMMMMMMMMMMMMMMMMX.      Shell: zsh 5.9 
;MMMMMMMMMMMMMMMMMMMMMMMM:       Resolution: 1800x1169 
:MMMMMMMMMMMMMMMMMMMMMMMM:       DE: Aqua 
.MMMMMMMMMMMMMMMMMMMMMMMMX.      WM: Quartz Compositor 
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.    WM Theme: Blue (Light) 
 .XMMMMMMMMMMMMMMMMMMMMMMMMMMk   Terminal: tmux 
  .XMMMMMMMMMMMMMMMMMMMMMMMMK.   CPU: Apple M3 Pro 
    kMMMMMMMMMMMMMMMMMMMMMMd     GPU: Apple M3 Pro 
     ;KMMMMMMMWXXWMMMMMMMk.      Memory: 2875MiB / 18432MiB 
       .cooc,.    .,coo:.

My guess is that there is a very slight difference between my MacBook M3 Pro and yours.

[TotallyGamerJet]

Very strange. I'll try to find what could be different

[TotallyGamerJet]

Ok, I figured it out. I had Stage Manager enabled. After I disabled it the app seems to work as expected. Now why does stage manager cause the issue 🤔

[TotallyGamerJet]

The problem is (*UserInterface).iconifyWindow(). There is a for loop in this function that checks if the window has been iconified with u.window.GetAttrib(glfw.Iconified). The issue happens when using MacOS's Stage Manager feature when the window is "minimized" it is still visible in the side panel so [window->ns.object isMiniaturized] in cocoa_window_darwin.m never returns true which means the for loop is never broken. Changing the line to [window->ns.object isMiniaturized] || ![window->ns.object isMainWindow]; fixes the issue. I'm not sure this is the intended behavior or not while using Stage Manager. Perhaps, instead the iconifyWindow function should be updated to ensure the app is placed in the app tray instead of stage manager?

This behavior is reproducible even in standard glfw 3.3:

package main

import (
	"fmt"
	"runtime"

	"github.com/go-gl/glfw/v3.3/glfw"
)

func init() {
	// This is needed to arrange that main() runs on main thread.
	// See documentation for functions that are only allowed to be called from the main thread.
	runtime.LockOSThread()
}

func main() {
	err := glfw.Init()
	if err != nil {
		panic(err)
	}
	defer glfw.Terminate()

	window, err := glfw.CreateWindow(640, 480, "Testing", nil, nil)
	if err != nil {
		panic(err)
	}

	window.MakeContextCurrent()
	var i = 0
	for !window.ShouldClose() {
		// delay the iconify process so the window can be fully loaded
		// if it isn't fully loaded then the Iconify function actually does
		// put the app in the tray.
		if i > 1000 {
			window.Iconify()
		}
		i++
		fmt.Println(i, window.GetAttrib(glfw.Iconified))
		// Do OpenGL stuff.
		window.SwapBuffers()
		glfw.PollEvents()
	}
}

Should we create a ticket in the GLFW project?

[hajimehoshi]

That's interesting. This seems a bug in GLFW. If this is a serious issue, I'm fine to fix this in our internal/glfw.

Should we create a ticket in the GLFW project?

Yes, if we can reproduce this without the Go binding.

[TotallyGamerJet]

I don't think this is a serious issue since it only happens with Stage Manager enabled, and minimizing the window in software. The yellow minimize button works as expected. If you wanted a simple temporary fix you could just limit the number of attempts the for loop does to check if it has been minimized

[hajimehoshi]

Sure. As this is not a serious issue, I'd like to hear what the GLFW people would say for this issue. Then let's consider how to fix Ebitengine (the best thing is to cherry-pick GLFW's fix)