Subpar FPS compared to GLFW

[tinne26]

I made a simple test program that only paints the screen yellow, in windowed mode and 640x480 resolution, both in GLFW and Ebitengine. The results are the following:

glfw v3.3 + gl v4.1: 2200fps (3200fps without gl.Clear)
ebitengine v2.4.3 + directX: 415fps
ebitengine v2.4.3 + openGL: 1215fps

I've made a couple gists for the GLFW code and the Ebitengine code that I used to obtain these results.

While these are toy programs and we shouldn't immediately jump to conclusions (for example, notice how using or not using gl.Clear has a drastic effect in GLFW's performance (gl.Clear is a very expensive operation, though)), two things stand out:

• There may be appreciable room for improvement in Ebitengine's performance even while using OpenGL. That said, it's unclear where the differences may come from (they may be unrelated to the graphics backend).
• DirectX may still be lagging significantly behind OpenGL, being between 6 and 8 times slower than GLFW in this example. That said, in more complex programs I'm typically seeing DirectX being only 40% slower than OpenGL (instead of more than twice as seen here).

[tinne26]

Checked GPU/CPU/RAM usage for the programs on Windows 11 (with the task manager, don't know how precise the values are):

• Both GLFW and Ebitengine with OpenGL have similar CPU and GPU usage (~12% and >90%). GLFW seems to hover closer to 95% GPU, while Ebitengine may be slightly lower at 93%, but they are very similar overall, so the difference is probably due to the efficiency of the operations used or other issues, not underusage of the GPU. RAM for GLFW is around 25MB while on Ebitengine it's twice that, around 50MB.
• DirectX has a GPU usage of around 40%, way lower than OpenGL, which suggests underusage of the GPU. RAM is still 50MB, and CPU is lower than OpenGL versions, but it's not surprising as the framerate is significantly lower than the OpenGL versions.

I think GPU usage values can be quite revealing.

[corfe83]

Have you tried the latest build in 2.5? I'm curious if this change affected things at all: https://github.com/hajimehoshi/ebiten/issues/2375

The issue in that linked bug turned out to be not specific to android, and since it's in restorable images, I believe it affects both directx and opengl.

[hajimehoshi]

2375 should affect only Android.

[corfe83]

I see. Thanks for clarifying.

[tinne26]

@corfe83 funny story: I actually saw the issue and caught the commit by chance when not even 5 minutes had passed! I immediately tested it but nothing changed, and I imagined something along the lines of what Hajime said. I was also hyped by that commit, hahaha.

[tinne26]

Today I tested ebitenginesinglethread and v2.5.0 to see if there were any changes. Everything remains the same. But I've had another idea... is it possible that Ebitengine's atlasing is causing a non-trivial texture send to the GPU, explaining part of the difference? In contrast, GLFW only sets up a simple shader, but may not be transfering any texture info. I was wondering it this could be tested in any way. It may have nothing to do with it, I don't know enough about Ebitengine's internals regarding this specific point, but it doesn't sound that crazy either.

Edit: or maybe, knowing Ebitengine's exact atlas size, we could try to pass a texture of the same size to GLFW to level the playing field?