Does MapLibre take advantage of GPU-accelerated vector tile rendering?

[jesussmile]

Hey Josxha,
I've been following your progress on the maplibre plugin closely, like a lot of other people. But I'm torn between your package and the layer option in flutter_map, which I also think is a great idea. My main concern is performance again. If I use it with flutter_map, will it be just as fast? You mentioned there were some limitations. What exactly are they?

[josxha]

Does MapLibre take advantage of GPU-accelerated vector tile rendering?

Yes, the MapLibre SDKs use the GPU for rendering.

My main concern is performance again.

May I ask why you consider flutter_map in general if your main concern is performance? While flutter_map has some performance tweaks, I'd say its strengh lays in its wide platform support, not performance.

If I use it with flutter_map, will it be just as fast?

The flutter_map_maplibre package provides two options. The MapLibreLayer includes a MapLibreMap widget as a layer in the FlutterMap widget. The FlutterMapAdapter on the other hand allows to use FlutterMap layers (or even some flutter_map plugins) on top of the MapLibre map.
In general flutter_map does not intervene with MapLibres' rendering, so yes, there shouldn't be any major performance loss.

You mentioned there were some limitations. What exactly are they?

I wouldn't recommend to use the MapLibreLayer on Android at the moment, because it is not stable yet. See #54 for more information.
The FlutterMapAdapter should be alright to use.

Known limitations of the MapLibreLayer:

• Limited to map gestures provided by flutter_map.
• Can't use the MapController by maplibre.
• Currently some problems with state management: [BUG] High delay of the MapLibreLayer on Android #54
• While the synchonization delay btween maplibre and flutter_map is quite good on web, the user experience suffers on android. A similar issue has been described here for maplibre/flutter-maplibre-gl: [BUG] Motion blur on custom markers maplibre/flutter-maplibre-gl#486 It will improve slightly in one of the next flutter releases but will stay for now.

Known limitations of the FlutterMapAdapter:

• Limited to map gestures provided by maplibre.
• Can't use the MapController by flutter_map.
• Can't tilt/pitch the camera as flutter_map does not support it.
• The flutter_map layers are not 100% smooth when moving the map around.

Quick note: there is an hosted example app avaiable where you can test both options on web:

• MapLibreLayer
• FlutterMapAdapter

[jesussmile]

May I ask why you consider flutter_map in general if your main concern is performance? While flutter_map has some performance tweaks, I'd say its strengh lays in its wide platform support, not performance.

I fly in a very mountainous region, so I decided to build a free navigation app with waypoints and terrain data for terrain avoidance. I have some programming background, but it's more of a hobby for me. As the app progressed, I added a worldwide database for airports and waypoints, along with polylines resembling airways and various charts overlaid on the map. This is a massive amount of data. It works fine with some modifications in Flutter_map, but I feel it's not quite as smooth as other apps I've seen. I didn’t think much about it until I accidentally came across MapLibre, which sparked my curiosity about switching to it. Of course, I can't maintain the same app on different platforms, so I chose Flutter. I also considered creating a plugin with my limited knowledge, but that seems like a distant goal. I tried to use your project as my base and modify it to fit my need but its a lot different than other plugin and I have never understood 'Pigeon'. Any suggestion is welcome. https://jesussmile.github.io/flutter_map_terrain.github.io/

[josxha]

As the app progressed, I added a worldwide database for airports and waypoints, along with polylines resembling airways and various charts overlaid on the map. This is a massive amount of data.

Now I see. The SymbolLayer or MarkerAnnotationLayer in MapLibre is indeed be the more performant choice to display large amount of data on the map. The MarkerLayer on the other hand is currently not as optimized as the MarkerLayer in flutter_map but if performance is crucial I'd stay away from too many widgets on the map in general. 😄
I'd say give it a try and feel free to share you experiences and problems.

I also considered creating a plugin with my limited knowledge, but that seems like a distant goal.

You're welcome to do so. A quick note: I follow a bit of a different approach than flutter_map. While flutter_map outsources a lot of core capabilities like caching, animations or geojsons, maplibre should contain all important functionality under the hood to ensure a higher level of integrity. Of course for more specialized uses there is a similar plugin API available as flutter_map provides. But if it's something a lot of users could use, you are welcome to contribute it directly to the repo.

I have never understood 'Pigeon'

One option to communicate with native code on flutter is by using a thing called method channels. Its basically a way to pass information to for example kotlin or vice versa. The catch is that only basic types like Strings, ints or Maps are possible to send and need to be parsed. Pigeon is a code generator that helps with that. It generates the necessary bindings so that you can send even dart objects and recieve kotlin objects in the end.

[jesussmile]

Hey @josxha, thanks a ton for your super detailed answer and for always being so helpful. I think it'd be better if I work with your plugin and try to contribute as much as I can. There's just one thing I don't get. If there was method channel, (the legacy way to create plugin) I could edit the native code and then work with it. But in this case with pigeon, if I update or edit the native code, do I need to generate the edits with pigeon too? This part is a bit confusing. I'll try to check it with iOS as well.

[josxha]

I agree that this is quite confusion at the moment. I need to clean up and document the development at some point. There are two different code generations used in this package:

pigeon

All files that have a *.g.* (e.g my_file.g.dart) filename are generated by pigeon. Those generated files shouldn't be edited directly. The only file that should be a edited is /pigeons/pigeon.dart. This file must not have any other imports. The generation can be run with /pigeons/run_code_gen.sh or /main/pigeons/run_code_gen.ps1 (or by running the commands manually).

jnigen

This allows interop with native java and kotlin code. jnigen generates ffi bindings to c and uses jni c bindings for java/kotlin. This does not only sound confusing but is sometimes a bit tricky to work with. The benefit is that it is in most szenarios faster than using method channels. Ideally we'd use jnigen for all calls into native code but jnigen is still not stable. There is no reliable way to call into dart from java/kotlin. I even experienced some dead locks when using callbacks. Probably my fault but I kept the method channels in because of that. The code generation for jnigen is a bit more complex but all relevant classes should already have dart bindings.

1. Download maplibre android aar file in the correct version from maven and copy it to /main/example/android/MapLibreAndroid/
2. Modify all lines that are marked with // JNIGEN. If the comment is before, make those lines active, if the comment is behind, comment the line out.
3. Build the example app with cd example and flutter build apk.
4. Run the code generation with dart run jnigen --config jnigen.yml (or by using /run_code_gen.ps1)