refactor: migrate tile rendering from widgets to CustomPainter

[JaffaKetchup]

Superceeds #1853 & continues #1908 targeting master.

[ReinisSprogis]

Hi. Any insights on this? That CPU usage is still very high. This was cutting it down by half or more. I don't know if there are any other plans to reduce it.

[JaffaKetchup]

I couldn't find an improvement in performance as big as was suggested on a non-web platform, but I'll go back and see if I can do some more detailed testing (as it wasn't massively detailed before). There wasn't an immediate plan to merge this, but it's definitely something we can consider in the short-to-mid term.

[ReinisSprogis]

It is the WEB platform that has slow performance.

[JaffaKetchup]

We're still looking towards potentially merging this, but we will need to just verify that loosing the ability to render widgets over tiles is acceptable. I'm not 100% sure it is without a good workaround.

[ReinisSprogis]

Hi.
I'm currently working on a plugin that requires rendering widgets over tiles. I found that the current custom tileBuilder approach is not ideal. It requires a function that returns a Widget, which makes it easy to implement, but it introduces various issues with state management (Helper methods). Since the widget gets disposed and rebuilt on every map event or state change, maintaining state becomes problematic. To work around this, I ended up creating a new layer that recalculates how tiles are laid out, ensuring synchronization with map tiles based on the MapCamera. However, this results in duplicated logic: the TileLayer does the layout once, and then I recalculate it again in my custom layer. While this approach works, it would be much better if the tile API were exposed in a similar way to MapCamera.

I'm not entirely sure how that would be structured, but if tileBuilder could be replaced or extended to expose visible tiles, their positions, XYZ-key and sizes, it would allow developers to overlay widgets properly. With that you could still use this CustomPainter if desired without loosing the ability to render widgets over tiles.

[JaffaKetchup]

Hey @ReinisSprogis :)

We are actually planning to move ahead in some form with a new primarily canvas-based tile layer as we move towards better support & integration for other tile types.

Of course this issue if overlaying widgets onto the canvas is still unresolved. So what you are talking about is a very good point to consider in any new implementation in that we might require lower level and more state-integrated control of widget tiles. I guess it would be the same for a canvas layer as well. I'm not sure yet how everything will fit together, but we'll try to cover as many bases as possible ofc.

The idea is that we create a base tile layer and a few implemented variants, but it becomes much more extensible for end users to implement a custom tile layer if required.

[JaffaKetchup]

See #2120. I'm going to close this PR as replaced by that - however, this is still a very useful resource that I will keep referring to to implement the new raster layer, so thanks @ReinisSprogis :)