You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in the JS decoder all geometries are fully materialized in memory for all features when a layer is decoded.
But we can on-demand/lazy parse geometries for radically more efficient decoding performance. This will result in less allocation overhead in Maplibre to have geometries requested on-demand.
Currently the JS benchmarks are written to compare on-demand geometry decoding of MVTs with https://github.com/mapbox/vector-tile-js against non-deferred, fully materialized geometry decoding of MLT. So the benchmarks are not really 🍏 to 🍏 until this feature is landed.
Currently in the JS decoder all geometries are fully materialized in memory for all features when a layer is decoded.
But we can on-demand/lazy parse geometries for radically more efficient decoding performance. This will result in less allocation overhead in Maplibre to have geometries requested on-demand.
Currently the JS benchmarks are written to compare on-demand geometry decoding of MVTs with https://github.com/mapbox/vector-tile-js against non-deferred, fully materialized geometry decoding of MLT. So the benchmarks are not really 🍏 to 🍏 until this feature is landed.
See also more context at #197
The text was updated successfully, but these errors were encountered: