Reduce the amount of data uploaded to the GPU

[mourner]

One of the things that affects GL JS rendering performance linearly and that we can track reliably is the amount of data we upload to the GPU for rendering (given the same style). Specifically, the total size of data given to bufferData calls.

There are two directions we can explore for this — fixing older regressions and finding new ways to upload less.

Fixing regressions

Looking at historical metrics of how much data we upload throughout previous GL JS version, I found 3 regressions:

• As a result of Unignore fill-opacity property-function test #3061 and Ensure fills with transparent colors and patterns are rendered as expected #3120, we upload data for zero-opacity layers, which can significantly increase the amount of unnecessarily uploaded data for some style/zoom combinations. On z11.1 Mapbox Streets v10 sample, it's a ~12% regression.
• In Use separate attribute elements for line normals #5073, we had to introduce a ~25% regression to work around a GPU bug on old Android phones. @ansis believes we can win this back while keeping the bug fixed by packing normals differently. PR Switch back to a more compact line attributes layout #8306
• Introduce an explicit "upload" step to rendering #5184 has a ~5% regression but I'm not sure why. Needs to be investigated. due to uploading line index data for fills even if it's not needed (fill-antialias is false).

Adding new savings

Some things we could explore from the top of my mind:

• Using instanced rendering (see also Use ANGLE_instanced_arrays extension to reduce buffer sizes for layers with property functions #1898) to significantly reduce vertex buffers. Should be pretty straightforward for instancing things like circles and heatmap kernels (4x reduction). It will be harder to take advantage of this for lines/fills, but we should explore possibilities.
• Revisiting how we tesselate lines and seeing if we can reduce the amount of triangles generated for line joins and line caps. Related: A more accurate algorithm for approximating round line joins #8275

cc @ansis @kkaefer

[mourner]

#5184 has a ~5% regression but I'm not sure why. Needs to be investigated.

Turns out the overhead is in fill layers with fill-antialias: false. Previously, since we uploaded buffers on render, we didn't upload line index data for outline rendering if it's not drawn. Now, since we upload buffers beforehand, line index data is uploaded regardless whether we need it or not. cc @ansis

[mourner]

As a result of #3061 and #3120, we upload data for zero-opacity layers, which can significantly increase the amount of unnecessarily uploaded data for some style/zoom combinations. On z11.1 Mapbox Streets v10 sample, it's a ~12% regression.

This is also something that's now hard to fix because of the coalescing of buffer uploads independently of drawing (#5184). However, it's probably not worth fixing because it's rare to have affected layers in newer, expression-based styles (which usually have feature-based rather than global zoom-based opacity set).