SetFullscreen can take several seconds on macOS

[quasilyte]

Ebitengine Version

Tested on latest main + v2.10.0

Operating System

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

Go Version (go version)

1.25.5 + 1.24.9

What steps will reproduce the problem?

Toggle a ebiten.SetFullscreen() to true/false during the game already running.

It's less apparent with example/windowsize, but it is very noticeable in larger games (with more images loaded into atlas?).

What is the expected result?

No freeze after SetFullscreen (as there is no freeze on Windows or Linux).

What happens instead?

A 4-6 seconds window freeze on my game and a little hiccup on windowsize example.

Anything else you feel useful to add?

Note that it does not happen if I set the game to a full screen before doing a RunGame - the first screen mode is applied without an issue, but if I call it after the game has launched, it causes a freeze.

If I measure the time needed to call a SetFullscreen, I get small numbers on my game:

51.135458ms

I tried using an os.Exit with time.AfterFunc to see if it's a complete app freeze or whether Go app still is running. It looks like the app is still running (not suspended), and the app can exit after a second even though the game looks frozen.

Another observation: the game's Update is still being called, but somewhere around 3-5 times per second with TPS being set to 120.

Here is what ActualFPS and ActualTPS calls report:

0 0 -- it's usually 0 for both

0.9978768921772813 0.9978768921772813 - and sometimes it's a very small value like 1FPS

This frozen state lasts for around 5 seconds, after that the game reports normal FPS/TPS values again:

60.9819020232422 119.99664591670239

And it also stops being frozen.

uname -a
Darwin Iskanders-MacBook-Air.local 24.6.0 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T8132 arm64

Also tried on another macbook (M1 Pro):

uname -a
Darwin mbp.local 24.6.0 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000 arm64

go env
AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='c++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/quasilyte/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/quasilyte/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/wy/vgml2f692h17svyc9ky14h080000gn/T/go-build111142089=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/quasilyte/work/dronefleet-game/src/go.mod'
GOMODCACHE='/Users/quasilyte/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/quasilyte/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.25.5/libexec'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/quasilyte/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.25.5/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25.5'
GOWORK=''
PKG_CONFIG='pkg-config'

[quasilyte]

I tried to minimize cut off the stuff from my game to see what causes that behavior. So far I can't figure out what's causing this drastic change in time needed to do it in windowsize example vs my game.

• I tried not loading the image assets so the game atlas is nearly empty (although not entirely empty of course)
• (more details may come later)