Proposal for pipelining the rendering

[alasram]

The Tracy profiler shows MapLibre is mostly GPU bound when rendering a complex style on a high end laptop. An example on i9-11950H and its iGPU:

When running the same content on a lower power system, i.e a Qualcomm Adas chip, the profile significantly changes:

MapLibre becomes a bit CPU bound with GeometryTile methods such as setData (simply copying and passing image data to worker threads) becoming very slow and createRenderTree taking milliseconds therefore starving the GPU.

Optimizing geometry and render tree creation would be very beneficial for lower-end hardware but a first simple method to alleviate performance is to pipeline the renderer. Instead of:

The Render thread will be split into multiple threads and pipelined:

A simple implementation is to have persistent threads GeometryTile, RenderTree and Render. A thread safe producer-consumer FIFO sits between each pipeline stage (the arrow in the above figure). The size of the FIFO controls the depth of the pipeline: compromise between how far behind the rendering is and the memory overhead of a deep queue (Not sure if the existing mailboxing method used in MapLibre can be leveraged for this pipelining purpose).