perf!: add simplification and segment culling to PolylineLayer & simplification to PolygonLayer

[mootw]

adds an optional (enabled by default with conservative values) simplification step to polygon and Polyline layers.

the default value is 1 decimal degree at zoom level 0, which is scaled based on the floored zoom level. this is similar to leaflets default simplification of 1 logical pixel. i would rather this value be based on logical pixels, but i did not know an easy way to adjust the pixel scale to be static based on the zoom level. leaflet only calculates this value after the projection and uses pixels, but as far as im aware they avoid the issue of in-between zoom levels by not calculating offsets between them and enforcing whole zoom levels. I attempted to calculate the pixel scale using the camera context but was not successful.

using logical pixels lead to the lines jittering too much, so only having them simplified in incremental steps is less obvious.

[JaffaKetchup]

As discussed, we should probably also think about fixing the culling code to work within elements, particularly for polylines.
For example, a long polyline currently needs to be manually broken into separate Polylines to benefit from culling. It may be a good idea to leave one 'path' (ie. a segment of a polyline) either side of the camera's viewport outside of bounds, so that a false end can never be seen.
Not sure how it could work with polygons? Is drawing a straight line when out of bounds good enough?

[ignatz]

Skimming the PR, IIUC you're simply merging neighboring points if they'd end up round about on the same pixel?

Right now you're re-simplifying on every draw. Since the merging is zoom-level dependent could we do some caching, so that there's less work to be done when panning/rotating?

FWIW, I'm personally already doing quite a few zoom-level-dependent gymnastics, e.g. fading certain polygons in and out. I'd be interested in having the tooling standalone as opposed to just integrated into the poly layers. In that case I can have a single merging pass with Polygon' = f(Polygon). Is that something you've considered?

[ignatz]

One more drive-by comment, I realized that your merging logic computes the distance between two map coordinates as cartesian. While that's a reasonable approximation at the equator, it's not so much towards the poles. You might run into some funny business. At least whatever threshold you set, will apply very differently.

[mootw]

i really want the simplification and culling margin to be based on the render pixel rather than the scaled latlng, but there are a couple trade-offs on both sides. definitely a TODO item though.

[JaffaKetchup]

Just these few things left (2 carried over from my last review).

[mootw]

still want to look into using pixels instead of zoom levels + degrees; unless we want to merge fairly quickly which I'm totally ok with how it is. Technically there is not a ton of difference between the two values, because map size is based on virtual pixels so in the end the simplification is more or less based on pixels anyways (minus any weird virtual pixel scaling). It's just easier to explain: simplify with a tolerance of 1.5 virtual pixels versus 1.5 decimal degrees at zoom level zero / (2^zoom) which when you multiply it back out gets you about 1.456623 virtual pixels or whatever.

[JaffaKetchup]

LGTM, thanks! I've made a couple of changes to the example app, let me know if you like them or not, and I've hopefully fixed the Windows app build.
Happy to leave this to the end of the week if you wanted to get the pixel-based tolerance stuff in, but do want to merge relatively soon so we can properly re-assess performance, etc.

[TesteurManiak]

LGTM! I don't know if you've been able to fix the performance issue, but I didn't seem to encounter any while testing the example. (I might not be testing in the correct conditions though)

[JaffaKetchup]

If you can't spot the poor performance, then it's worked :D

[josxha]

lgtm, awesome pr! 👍