Create render-to-texture renderpool to render terrain in paralell

[prozessor13]

This branch creates a Render-To-Texture render-pool, instead of caching textures in RTT Tiles.

Old logic:
The Terrain class had one framebuffer, and a list of tiles which contained a list of textures. This had two problems:

• for complicated stylesheets a lot of textures were created, for mobile-phones too much, and they crashed
• render the textures with only one framebuffer was slow, because serial rendering one by one

New logic:
There exist a Framebuffer/Texture pool that would be reused during rendering, and the tiles only contains indexes to this pool-objects.

• Now there is a single place to define the amount of created framebuffer/textures. Currently the pool contains 30 objects, not tested if this is too much for mobile phones
• because of 30 paralell framebuffer objects, and no need of heavily switching textures during rendering the rendering is much faster.

Also this PR makes my other PR #1301 obsolete.

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• unit tests - @prozessor13
• test different stylesheets and corresponding render-to-texture stacks (e.g. which layers are drawn in one pass to texture)
• render tests (will be reused from create a frame around render-to-texture tiles to avoid stiching on different zoomlevels (2. version) #1666)
• Add an entry inside this element for inclusion in the maplibre-gl-js changelog: <changelog></changelog>.

Need help with:

• Post benchmark scores.
• performance tests (i done that manually and in any case i get a much better performance, is this sufficient?)
• test if re-render on style-change works correctly, see #1301 & With terrain no redraw when setting layer visibility to false or changing opacity #1461
• test if web-app crashes are gone, may play with POOL_SIZE in render_to_texture.ts.

[github-actions]

Bundle size report:

Size Change: +828 B
Total Size Before: 204 kB
Total Size After: 205 kB

Output file	Before	After	Change
maplibre-gl.js	195 kB	196 kB	+828 B
maplibre-gl.css	9.09 kB	9.09 kB	0 B

ℹ️ View Details

No major changes

[HarelM]

I've fixes most of the tests.
I've left one failing related to the changes in render to texture which I wasn't sure how to fix.
Let me know if you need more help in writing or or fixing the tests.

[prozessor13]

Hello Harel,

thank you for fixing the unit-tests. I will do the last missing tests. Additionally i can create tests with different stylesheets and check if the merging of layers works correct in render_to_texture.ts.

It would be great if someone else can:

• Create a render-test, may the existing one are sufficient?
• Test performance, e.g run, and my add, a benchmark test.

[HarelM]

I think the render test that will be added as part of #1666 will be enough for this as well.
Once this is merged I can create a pre-release to test the performance in my app.
Did you try it with the iPhone 6 device you have?

[prozessor13]

Yes, tried on my iphone, and works much more performant without a crash.

[HarelM]

Overall this looks good.
I have added some last comments.
Let me know if you need help working on either of them.

[prozessor13]

@HarelM thanks for review! Are there more tests needed for testing performance? I am sure this branch increases performance, but i have no idea how to create a performance-test. Help with this would be great!

[HarelM]

I've made the changes myself to reduce cycle time.
A few notes related to the pool class:

1. There's no actual check for the size of the pool when creating new objects so basically the pool can be bigger than the size you initialize it with.
2. The recently used is never bigger than objects array so there's a check that is always false and code that never gets executed.

I found out about both issues when I ran the tests and looked at the code coverage which is a great things when you create new classes that should be fully tested. :-)
The line I used is:
npx jest ./src/gl/render_pool.test.ts --coverage
and check the line coverage of render_pool under gl.

This is not holding this PR from my point of view and can be fixed in a later PR.

[prozessor13]

@HarelM thanks for your changes, and interesting result from the coverage tool! Very helpful! This line is from the old, not working logic. Missed to think about this line, and delete it.
I can fix the issues tomorrow, if PR is already merged i will create a new PR.

[HarelM]

This can wait another day, I prefer to merge it with the relevant fix and not create a new PR for this.
Thanks a lot for all the hard work! Truly appreciated! :-)

[HarelM]

render_pool.ts | 100 | 100 | 100 | 100 Nice! 100% coverage!