ebiten
ebiten copied to clipboard
hajimehoshi
examples/windowsize: pressing N to minimizes causes app to freeze
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
The app freezes and becomes unresponsive even after returning focus.
It depends. You have to call SetRunnableOnUnfocused(false).
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.
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
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.
I'll try to update. macOS14.4 seems notorious
https://news.ycombinator.com/item?id=39741115
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.
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 🤔
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?
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.
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
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)