Godot 3.1 running slower than Godot 2.1.4

[Skaruts]

Godot 3.1 and onwards

Windows 7
ATI Radeon HD 4870
Intel Core Duo 2.13Ghz (OC at 3.6Ghz)

---

(Edited out irrelevant stuff)

On a straight comparison between Godot 2 and Godot 3 (in GLES2 mode), I found that Godot 3 renders things much slower, at least in 2D.

I don't know if this is a problem on my end, or if it's a GLES2 problem, but I'd like to find out. Below there's a zip file with two equivalent simple projects built on each godot version (2.1.4 vs 3.1), and I would appreciate if someone could confirm that this also happens on their side.

Simple Cell Rendering Test.zip

Both projects display a 64x40 grid of tiles from a cp437 font image, in three different ways, and I get these frame rates:

             godot 2.1.4  |     godot 3.1
	
TileMap       ~820 fps    |    ~215 fps        # using a TileMap
Sprites       ~215 fps    |    ~135 fps        # using Sprite nodes
Draw          ~420 fps    |    ~150 fps        # using 'draw_texture_region_rect()' in _draw()

As you can see there's a substantial difference.

[arkology]

Also, 3.1 is slower than 3.0 (at least in the editor for sure)

[jimmyjonezz]

Yes, if i use Tilemap (Godot 3.1) i have 350 fps, but if i have two Tilemap ~ 50 fps. It's so bad.

[marcelofg55]

Moreover, when profiling in Godot 3.1, I notice the Audio Thread and Audio Driver take a lot of frame time. They fluctuate, and a lot of the time they're over 50%, sometimes beyond 100%: I noticed a few frames over 300% or even 600%.

That's strange, if you set the audio driver to Dummy on the project settings (Audio -> Driver -> Dummy) do you still get those big numbers?

[Skaruts]

Moreover, when profiling in Godot 3.1, I notice the Audio Thread and Audio Driver take a lot of frame time. They fluctuate, and a lot of the time they're over 50%, sometimes beyond 100%: I noticed a few frames over 300% or even 600%.

That's strange, if you set the audio driver to Dummy on the project settings (Audio -> Driver -> Dummy) do you still get those big numbers?

@marcelofg55, if I use Dummy I don't have that anymore, but the frame rates stay the same. I did notice something I hadn't noticed before though: the Physics Frame Time is ~300% too, and its red line is perfectly steady at that. I took a screenshot of it.

(The error in the screenshot is the first one of those I listed before, related to gles2.)

EDIT: Although I just noticed that that also happens in Godot 2, and it's arguably even worse. But it still runs at way better frame rates, so it's probably unrelated (both screenshots were taken with the projects running with the TileMap node).

[ricardoalcantara]

This issue should be tagged as urgent to 3.2, it's because on Android mobile the frame drops below 60 fps just with two layers of Tilemap, My friend's making a game and his layers of tilemap alone made it run below 30 fps. I believe that this issue could make Godot 3.1 no viable for some kind of simple 2d games, or Am I overreacting?

[Calinou]

@ricardoalcantara Have you switched to the GLES2 renderer? Also try setting framebuffer allocation to 2D in the Project Settings, which should make performance better for 2D-only projects.

[ricardoalcantara]

Yes, I am using GLES2, "Framebuffer Allocation": "2D " and "Framebuffer Allocation.mobile": "2D Without Sampling".

[thrbr84]

I have the same problem with just one layer of tileset (grid of 34x34 tiles with size 64px) being very slow, my project uses 4 layers of tileset and in one of them navigation/A* is impossible to continue, very slow and very lag, in my case I noticed that practically happens only with Android 6.0 in PC and other superior Android versions goes well, do not know if it can make sense.

Godot 3.1 with GLES2 in project settings - Framebuffer Allocation 2D / .mobile: 2D Without Sampling

[vini-guerrero]

Hey guys...
Same issue here, using GLES2 on 3.1 with 3 tilemaps. Performance goes way to low on Android 6 devices, almost non-playable...

[mischiefaaron]

I upgraded my commercial game to work with 3.1 recently. It runs great in OpenGLES3, or at least is
a stable 60FPS. When I switch to OpenGLES2 however and enter the game mode, performance is so bad that it can't go above 30 and on the more taxing maps it goes down to 12. There can be up to 7 tilemaps used in one map and all of them with even just 1 or 2 tilemaps chug.

[ricardoalcantara]

I manager to replicate my project.
Tilemaps.zip
Three tilemaps from the size of my real game, same resolution and same project settings, In my game I have a Floor Tileset, Objects Tileset and now I added a Fog Tileset, but just the tileset runs with 18 FPS on my Moto G5S Plus, why? Is there any thing I could to to make it runs faster?

[Skaruts]

Also try setting framebuffer allocation to 2D in the Project Settings, which should make performance better for 2D-only projects.

I had overlooked this. Sadly the improvement on my end is very small. I only gained ~5-20fps depending on the Terminal I used.

[vini-guerrero]

Could this be related to the amount of tilemap layers? I have the exact same configs and even by reducing sprites resolution, mobile performance is pretty laggy...

[Skaruts]

@vini-guerrero the more tilemaps you use the lower the performance will be. That's expected behavior. In my case I was only using one and comparing between equivalent projects.

[Skaruts]

I cleaned up the OP and made it more clear.

I never got any confirmation from anyone that a comparison between equivalent projects in godot 2 and upwards of 3.1 has the same result. I'd like some confirmation to find out if it's a problem with my ATI card or if it's a problem with Godot itself, etc.

If anyone could still confirm I would appreciate it. (You can use the project I built (see the OP) for an easy exact comparison.)

[DegradedMind]

I am getting these results on i5 5300U, HD Graphics 5500:

Godot 3.1.2
Draw - around 100
Sprites - around 90
Tilemap - around 120

Godot 2.1.6
Draw - 200
Sprites - 180
Tilemap - 230

that's pretty low. i don't know if i am doing something wrong.

[lawnjelly]

Yesterday evening and this morning I profiled and had a look at the 2d rendering code for the OP's example. It is bottlenecked by the graphics driver, and it turns out the quads could be drawn much more efficiently.

• Biggest point (as others have suspected) is the quads should really be batched and drawn in one drawcall, or low number of drawcalls.

• Secondly, some of the current code is reusing vertex buffers to draw multiple 2d items per frame. This is highly likely to lead to bad performance, pipeline stalls, and possibly other visual bugs depending on drivers.

• Thirdly, there is currently no concept of state in the calling code. By keeping track of state and minimizing OpenGL state changes I have increased FPS by approx 40% in the example project.

I will shortly make a work in progress PR for the state changes and have a look at this with @clayjohn. The state change speedup is essentially free.

Batching should result in far higher performance increases (2d should really be fill rate limited) but may be more involved, we can probably get this working depending on interest (I saw there was a previous batching PR #20965 but it got reverted, possibly it was causing pipeline stalls, some care has to be taken with dynamic vertex buffers).

[lawnjelly]

Just a heads up, I now have batching working in a proof of concept for GLES2. It puts performance on a par with Godot 2.1 (or faster possibly, I don't know any details of 2.1), typically 3-10x faster. It puts the simple 2d games I have tested up to 500-1000fps or more in my Intel integrated GPU, or > 4000fps with small screen (i.e. they are now fill rate limited).

I have to test the method works ok on mobile / all platforms (with regard to vertex buffer usage and stalls, when taking into account the problems with the previous author's batching PR), and do some usability improvements (most of my tests have been with tilemaps so far, I need to check the other drawing methods get the speed boost properly), but barring regressions / problems on mobile I should be able to make a PR soon.

If the GLES2 works fine it is likely I can do similar in the GLES3 version (I'm presuming they use the same rough rendering method, I haven't looked yet).

[Calinou]

GLES2 batching is now available in Godot 3.2.2 onwards, closing. 3.2.4beta1 onwards also features GLES3 batching.

[Skaruts]

@Calinou
It just occurred to me that this problem may still exist.

On one hand, given that Godot 2 was faster without batching, shouldn't Godot 3 be as well?

On the other hand, I think I remember @lawnjelly mentioning somewhere that batching didn't affect all drawing methods. I think it was just sprite drawing, and maybe the TileMap as well. So if that's the case I suppose this issue still persists in those.

I'm just saying, though, I haven't done any actual testing. I might do that at some point.

[Calinou]

On the other hand, I think I remember @lawnjelly mentioning somewhere that batching didn't affect all drawing methods. I think it was just sprite drawing, and maybe the TileMap as well. So if that's the case I suppose this issue still persists in those.

As I linked above, batching was rewritten in Godot 3.3 to cover more primitive types (in addition to working in both GLES3 and GLES2).