Performance issue - Main isolate is blocked when encoding geojsonFeature

[T-moz]

Before sending geojsonFeature through the method channel, the data is encode.
Ex:

the function jsonEncode is synchronous, and if the is a lot of data, like a line of 40k points, the main isolate can be blocked.

This can lead to a UI freezed of n-seconds on the Flutter side.

See FlameChart:

[m0nac0]

A spontaneous idea (not saying this is necessarily better, but might be simpler): could we just expose an ("advanced") variant of the method that accepts a pre-encoded string, such that library consumers can decide how they want to do the json encode (e.g. on another isolate)

[T-moz]

A spontaneous idea (not saying this is necessarily better, but might be simpler): could we just expose an ("advanced") variant of the method that accepts a pre-encoded string, such that library consumers can decide how they want to do the json encode (e.g. on another isolate)

Yes this would also work, and I don't see any performances differences between the two solutions.
I think the direction we have to choose is how do you want the FlutterMaplibre API to be design.

• Should it be a large API, with many optimised and specialised methods ? (like updateLine and updatesLines).
• Or should it be a less wide API, with a lot of flexibility ? (Like exposing a method setFeatures that accept an encoded string, and the package's user is responsible for the encoding).
• Or maybe something else, we can ask four outside feedbacks.

My point of view, is that the package maplibre_gl should be a "deep module". Which means that the API exposed should not be very wide, and should handle most of the complexity.

[T-moz]

Should it be a large API, with many optimised and specialised methods ? (like updateLine and updatesLines).

I even think that updateLine can be remove and replace by updateLines.
Package's users could still update one line, and they would be encourage to batch updates.

The same goes for other methods.

[T-moz]

@m0nac0 I'm staring to think that your idea is better.
Because jsonEncode takes time, but decoding a polyline string, then adapting to latlng, and then converting to geojson also takes a lot of time.

Package user that display list of complexe polylines, should be able to do all that with one compute. And for that, the package needs to expose a lowLevel method, that accept encodedGeoJson.

I will try to expose a method addEncodedGeoJsonSource 🤞