Performance issue with DrawImage() in game.Draw()

[TLINDEN]

Ebitengine Version

2.7.4

Operating System

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

Go Version (go version)

1.22.1

What steps will reproduce the problem?

I wrote a small game of life clone using Ebitengine. It works nicely so far. But when I increase the number of cells above some certain amount, then CPU performance detoriates dramatically. FPS goes down to <5. If I enable CPU profiling on the game, the whole system freezes and needs a hard reset.

What is the expected result?

No issue with high cell (that is: image) counts.

What happens instead?

FPS goes down rapidly and the game becomes unresponsive.

Anything else you feel useful to add?

The source of the game in question is here: golsky. I was unable to actually get a non-zero profiling file using the ebitengine main loop. Therefore I created a fake main loop. Profiling can be initiated with these options:

      --profile-draw               profile draw method (default false)
      --profile-file string        enable profiling
      --profile-max-loops int      how many loops to execute (default 10) (default 10)

This is an example call which causes the FPS problem:

./golsky -W800 -H800 --profile-file cpu.profile --profile-max-loops 50 --profile-draw

My first thought was that my own code is the culprit, of course. But when I looked into the profiling results, it looked different:

So, in the game I pre-compute the tile images and in game.Draw() I just put these images onto the screen image.

Ok, I'm still new to game development (and even golang for that matter), so I'm pretty sure there might be lots of things I could improve in my code. But pprof says something different.

[hajimehoshi]

(I've moved this to the discussion forum. If I found an actionable item, I'll create a new issue)

Apparently atlas.DrawTriangles creates many objects, but I was wondering if there are other objects in your program.

[TLINDEN]

What do you think, would it be faster to use vector.DrawFilledRect()?
As long as the number of vertices doesn't change, the performance is the same.

I have tested it, the variant using DrawImage() is faster, but not by much.

It is possible to supply a slice as a uniform variable. ([]float32 or []int32).

But only one dimension, but not [][]int32? Because if it would be possible, I could just use one shader for the whole grid, which gets the current grid setup as a uniform and updates all cells accordingly - et voilà :)

While I'm thinking about it, what I could DO with one dimesion is to use one shader per row. Would still be better than lots of single DrawImage calls...

This is what I called "an offscreen", and I think this seems the way to go.

Yes, but I only do it for a part of the screen (background/grid + dead cells), then I copy the offscreen image into the world image and finally draw the life cells to it.

Would it be faster to do the last step offscreen as well and copying it only at the end?

[hajimehoshi]

But only one dimension, but not [][]int32? Because if it would be possible, I could just use one shader for the whole grid, which gets the current grid setup as a uniform and updates all cells accordingly - et voilà :)

Right, two dimensional slices are not supported so far.

While I'm thinking about it, what I could DO with one dimesion is to use one shader per row. Would still be better than lots of single DrawImage calls...

If the purpose is to reduce the number of DrawImage calls, I'd use DrawTriangles or DrawTrianglesShader by creating your own vertices. This means you will do a very similar thing to what Ebitengine does for DrawImage internally, but you can get your own optimized logic. What do you think?

Would it be faster to do the last step offscreen as well and copying it only at the end?

I'm not sure I understand what you did. What kind of items and images are there in your game?

• background
• grid
• dead cells
• live cells

? I though you rendered everything but live cells are rendered onto an offscreen once, and then rendered a part of the offscreen onto the final screen, and then rendered the live cells onto the final screen.

[hajimehoshi]

The indices would be like 0, 1, 2, 1, 2, 3, 4, 5, 6, 5, 6, 7, ... for rectangles. 6 indices should be added for 4 vertices = 2 triangles = 1 rectangle. In your code, 3 indices are added for 1 vector, and this is too much.

[TLINDEN]

Yes, I think I fixed the triangles generation. But as already discussed on Discord, at a certain amount of cells the output gets more and more artifacts. Source for the DrawTriangles variant.

So, as suggested I also build an example which uses WritePixels(): https://github.com/TLINDEN/testgol/tree/wrpixels. This works fine and is even faster (and without artifacts).

But even by using WritePixels I'm reaching a performance barrier > 1000x1000 cells. According to pprof measurements, this time it's not related to any ebitengine function calls, but seems to be caused solely by the functin which calculates the vertices for WritePixels: UpdatePixels().

So, I think at this point you're out of the issue, but I'd like to ask anyway: are there any further enhancements you might be able to suggest? I'm asking because I have seen much larger game of life grids in the past (and I'm talking about the 2 decades ago past).

However, thank you very much for your time and patiene! I know that this is not a given.

best,
Tom

[hajimehoshi]

Thanks!

So, I think at this point you're out of the issue, but I'd like to ask anyway: are there any further enhancements you might be able to suggest? I'm asking because I have seen much larger game of life grids in the past (and I'm talking about the 2 decades ago past).

TBH, I don't have a good idea. For a life game, you can utilize GPU to calculate the next state by utilizing parallelization. Go (and Ebitengine) doesn't have a good API or a library to do GPU calculation. Maybe Kage might be available but I have not tried for this purpose :-)