perf!: add simplification and segment culling to PolylineLayer & simplification to PolygonLayer
#1704
Conversation
|
As discussed, we should probably also think about fixing the culling code to work within elements, particularly for polylines. |
|
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 |
|
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. |
|
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
changed the title
Polylines and Polygons
JaffaKetchup
changed the title
Polylines and PolygonsPolylines and Polygons
Co-authored-by: Luka S <github@jaffaketchup.dev>
|
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. |
Removed high quality simplification option (and always use it) Added `Polyline.copyWithNewPoints` method Added temporary performance monitors Minor syntactic improvements Formatted Improved documentation Improved Polylines page in example app
…ading to multiple issues when hit testing was used in conjunction with simplification PARTIALLY fixed issue where simplified and culled `Polyline`s would be notified from hit testing instead of original, leading to multiple issues with the recommended documented method of interactivity handling Improved `_PolylineLayerState.didUpdateWIdget` logic efficiency Improved documentation Removed debugging/performance code Improved Polyline interaction example
…nge elsewhere Removed polyline simplification precomputer Reorganised polyline-related source files Fixed bugs and improved efficiency
JaffaKetchup
requested review from
ibrierley,
TesteurManiak,
josxha and
JaffaKetchup
and removed request for
ibrierley,
TesteurManiak and
josxha
|
If you can't spot the poor performance, then it's worked :D |
Minor improvements to Polyline example
Changed `simplificationTolerance` default to 0.5
to Polyline example
JaffaKetchup
changed the title
Polylines and PolygonsPolylineLayer & simplification to PolygonLayer
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.