Open venning opened 2 months ago
I'll take a look, but I am not sure this is fixable.
now := time.Now().UnixNano()
tps := 1_000_000_000/float64(now-then)
then = now
addMsg(fmt.Sprintf("%5.1f", tps))
This measures TPS (ticks per second), not FPS (frames per second). Ticks can be flaky so that you can expect Update is called 60 times per second on average. This is expected.
EDIT: You used SyncWithFPS
, so this measures FPS. I'm sorry.
I tested this on fullscreen (MacBook M3 Pro with power adapter):
Draw timings are pretty flaky and unstable, and as I said, I am not sure this is fixable. On average, FPS is stable as 120, so unfortunately I failed to reproduce your case.
I am not sure this is fixable.
Okay, I understand.
Can you keep this issue open? I would be interested in revisiting this if and when I upgrade operating systems or machines.
The more I use Ebitengine, the more I appreciate how weird operating systems make rendering.
Can you keep this issue open? I would be interested in revisiting this if and when I upgrade operating systems or machines.
Sure. I don't set a milestone, but I'm fine keeping this open.
The more I use Ebitengine, the more I appreciate how weird operating systems make rendering.
Thanks! Yeah, Ebitengine does a lot of things to handle weird things under the hood...
As a side note, This reminds me of the troubles that the developers of the Zed editor went through, the performance characteristics were wildly different on the different ARM processors. https://zed.dev/blog/120fps
(I'm recording this here more for posterity, as I will likely revisit this issue in the future. I don't expect this comment will result in any immediate change in behavior or understanding.)
@hajimehoshi Revisiting this, I studied your results a little more closely. (As a reminder: my computer was somewhat alternating between 120 FPS and 60 FPS to average to something around 90 FPS, but your computer seemed to be maintaining 120 FPS.)
However, I just now noticed that your computer seems to somewhat replicate what my computer was doing with the alternating 120 and 60, but occasionally your computer would have a tick-frame that happened so quickly it registered as >1000 FPS, which resulted in the average being 120. Presumably, this was Ebitengine attempting to compensate for the occasional 60 FPS "lag".
Is there some reason your computer would do that while mine would not? I imagine it's likely either just a difference between M1 and M3, or a difference between our operating system versions (I'm assuming you weren't on Ventura 13.1).
Ebitengine Version
2.7.8
Operating System
Go Version (
go version
)go1.22.2 darwin/arm64
What steps will reproduce the problem?
Run the following and toggle fullscreen by pressing [F]. It just measures the system time between Update calls (using SyncWithFPS) and calculates the effective FPS.
What is the expected result?
My laptop monitor is 120 Hz. While not in fullscreen, Ebitengine runs at ~120 FPS and the values of the effective FPS (as established by the above code) is roughly 120 FPS for each frame. This is as I would expect.
While in fullscreen, the FPS drops to ~90 (though sometimes as low as 77, I'm not sure why). Moreover, the effective timing of frames oscillates between ~120 FPS and ~60 FPS (which would average to 90). This is unexpected.
What happens instead?
This is not fullscreen:
This is fullscreen:
(Note, the printed FPS at the top of the images is affected by me taking the screenshots themselves.)
Anything else you feel useful to add?
I'm running these under Metal. The OpenGL version of this is wildly irregular; which, I assume, is why Metal is the default. However, OpenGL maintains ~120 FPS in fullscreen.
My guess is that MacOS is limiting the application to 90 FPS for its own reasons, but Ebitengine is reading the refresh rate at 120 Hz and its Draw call timing calculation is compensating; though I really don't understand enough of Ebitengine's internals to feel confident in that.
MacBook Pro 14-inch, 2021 Apple M1 Pro 32 GB Ventura 13.1