Fix GLES2 rendering performance

[dragmz]

Fixes a problem described in #19943 but for GLES2 only. The fix reduces the number of glBufferSubData calls by splitting canvas rendering into two phases:

1. Prepare polygons data and send the data to GPU
2. Render the polygons from the GPU buffers

I'm getting 4-10 times performance boost for the project attached to #19943 when run with "--video-driver GLES2" flag.

Performance tests (FPS comparison [after vs before]):

Core i5-650, GTX 950:

• 480 polygons: 730 vs 330 = 2,21
• 1920 polygons: 270 vs 92 = 2,93
• 7680 polygons: 72 vs 25 = 2,88
• sprites: no change

Core i7-4790K, Intel 4600:

• 480 polygons: 325 vs 60 = 5,42
• 1920 polygons: 185 vs 19 = 9,74
• 7680 polygons: 77 vs 5 = 15,4
• sprites: no change

Core i3-2310M, Intel 3000:

• 480 polygons: 60 vs 10 = 6
• 1920 polygons: 24 vs 3 = 8
• 7680 polygons: 7 vs 1 = 7
• font rendering (using text_rendering.zip project attached below): 140 vs 10 = 14
• sprites: no change

Android (Moto C):

• font rendering: 57 vs 4 = 14,25

Tasks:

• Split rendering into prepare and flush phases
• Support multiline polylines (draw_multiline)
• Do performance tests on different hardware
• Implement draw calls batching for font rendering ( Text rendering performance low due to missing batching #19917)

[dragmz]

Test project (from #19917) with vsync turned off, Add More Text modified to add 50x more text at once, GLES2 video driver set by default and number of draw calls displayed:
text_rendering.zip

[karroffel]

Looks good generally! I didn't completely check every single memcpy and glXXX command, but the general architecture is pretty good! I think time will tell if there are bugs 😛

[karroffel]

I think most compilers will deal with this just fine, but technically this would create a VLA (which are not part of the C++ standard), so making this static const uint8_t count = 6; would be more "safe", but not priority.

[dragmz]

Closing because the canvas rasterizer is expected to have all or none batching and not a partial batching that's been proposed here. See https://godot.eska.me/irc-logs/devel/2018-07-25.log [16:56:58] - [17:13:35] for details.

[akien-mga]

I understand that @reduz wants something even more exhaustive, but what are the drawbacks of the current implementation? It fixes real world issues that should not be disregarded.

[groud]

That's quite unexpected.We can't change the whole code all in once.
Too bad you did close this PR.

[dragmz]

@groud I have closed it because I can't reimplement it in a near future to have full batching.

[groud]

I know, but it could have been merged until someone can.

[dragmz]

@groud I can't (and don't want to) force @reduz to merge it 😄I'm sure Godot will get some proper 2D batching one day 🤞

[PtrMan]

The code doesn't seem to be hard to understand (hey it's just rendering code) but it still could be split into a few commits