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

TotallyGamerJet commented 3 months ago

Ebitengine Version

@d15b12b4

Operating System

[ ] Windows
[X] 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 commented 3 months ago

The app freezes and becomes unresponsive even after returning focus.

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

TotallyGamerJet commented 3 months ago

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 commented 3 months ago

Oh? I'll try

hajimehoshi commented 3 months ago

I failed to reproduce this.

                    'c.          hajimehoshi@Hajimes-MacBook-Pro.local 
                 ,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 commented 3 months ago

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 commented 3 months ago

What is your macOS version?

TotallyGamerJet commented 3 months ago

Version 14.4 (23E214)

hajimehoshi commented 3 months ago

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

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

hajimehoshi commented 3 months ago

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

                    'c.          hajimehoshi@Hajimes-MacBook-Pro.local 
                 ,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 commented 3 months ago

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

TotallyGamerJet commented 3 months ago

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 commented 3 months ago

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:

```go 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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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)

hajimehoshi / ebiten