Accelerate 2D by tracking state client-side

[lawnjelly]

GLES2 only first.

Godot 2D performance is usually bottlenecked by the methods used with OpenGL, there are currently drawcalls per quad.

In this PR basic state tracking is added to rasterizer_canvas_gles2::_canvas_item_render_commands().

This gives a 'free' performance increase of around 40% frames per second in a test scene, while requiring minimal changes to the overall mechanism.

Notes

• I have been using the test project in this issue Godot 3.1 running slower than Godot 2.1.4 #27230 with the tilemap selected as the one under test.

• The actual speed increase will scale with the number of Rects being drawn. There is also likely to be more benefit on some hardware / platform combinations than others, all should receive some benefit.

• The best solution to this problem is batching, which will give far greater performance increases. But this might help as a simpler interim solution.

Mentioning @clayjohn as we discussed this yesterday.

[clayjohn]

Changes look good so far. Definitely some style changes are needed to bring this into the Godot style. I am getting a speed increase, however mine is slightly less pronounced, more like a 20% boost (still extremely good).

I am however, getting a crash coming from line 869. Looks like _bind_canvas_texture() doesn't always return a valid texture.

Also, at some point we should extend this to other commands.

This is a very good start!

[lawnjelly]

Changes look good so far. Definitely some style changes are needed to bring this into the Godot style. I am getting a speed increase, however mine is slightly less pronounced, more like a 20% boost (still extremely good).

I am however, getting a crash coming from line 869. Looks like _bind_canvas_texture() doesn't always return a valid texture.

Also, at some point we should extend this to other commands.

This is a very good start!

Yup, I've just fixed a crash when there was a NULL texture (needed to check for this), and there's still a state that needs refreshing because project settings in the editor isn't drawing correctly, but am almost there. 👍

[clayjohn]

Not too many nitpicks! Looking good so far.

From my brief testing it appears all the crashing is gone. I will do further testing before approval

[clayjohn]

Should be Item::Command type instead of int

[lawnjelly]

Only reason I used an int at the time was because I needed a way or specifying 'unset' (and used -1) as the enum didn't have a NULL value. I'll have a look tomorrow whether it is possible to add to the enum without affecting other bits of the codebase, as agreed that would be better.

[clayjohn]

Ah, may be best to add a "state_dirty" boolean or something similar then. The benefit of using the Enum is that we get the compiler to enforce a lot of static error checking stuff.

[lawnjelly]

I had a look at putting a null value into the enum (as this will be the fastest at runtime and clear) and it was doable, so I have gone ahead with this, although it does mean adding extra case statements in a couple of other files to prevent compile warnings (switch not using all the enum values).

It doesn't look like the extra value in the enum will affect anything else (there is no use of the enum for determining array sizes for example), and shouldn't have any significant effect on jump tables. I've put the null value as the first in the enum (as is usually tradition). It could be named something else like 'TYPE_UNSET', but null seems quite language agnostic.

[clayjohn]

For future reference. This PR only optimizes the use of TYPE_RECT objects. However, that encompasses the majority of objects used in 2D in Godot (e.g most GUI, Sprites, tilemap)

[clayjohn]

Looks good! I like how simple the implementation feels. I think it will be easy for others to understand. And it will be easy for us to add other command types when needed.

[volzhs]

@akien-mga is not available for 3.1.x?

[akien-mga]

We can consider it for 3.1.x too if there's demand for it yeah.

[volzhs]

I use 3.1.x for real project. if it's good enough, we could adapt it for 3.1.x for boosting performance. :)
many users would be happy with it.

[lawnjelly]

Closing for now as superseded by batching PR #35957 which is much faster.

[clayjohn]

@lawnjelly This is still relevant for code paths that dont take advantage of batching and for users that disable batching.

[arkology]

I also think it's still relevant. Because godot really need performance.

[lawnjelly]

Ah ok sorry, I'll leave open. 👍

[Calinou]

Is this PR still relevant following the merge of unified GLES3/GLES2 batching?

[lawnjelly]

I'd be in favour of closing it and just archiving it for reference. Few people should be using the legacy path now, and the batching by nature has far fewer state changes.

[clayjohn]

I agree.