What are the advantages of using this package?

[jesussmile]

Hi Josxha, I just started working with flutter_map and Flutter in general. I previously tried the maplibre_gl package, but it had issues displaying multiple markers and synchronizing marker movement with the map, so I had to abandon it. This package looks very promising, and I'm eager to learn more.

I would like to educate myself, like many others, about MapLibre and its benefits. First of all, is it only compatible with the Mapbox SDK and I need mapbox tokens ?, or can I use it with my own maps? Most importantly, is it free and independent of other libraries for map styling and offline usage? What kind of performance can we expect in general?

[josxha]

Hi @jesussmile, I want to create a comparison site one day but I hope some checkpoints will do it for now.

is it only compatible with the Mapbox SDK and I need mapbox tokens ?

The MapLibre team works togehter with sponsors on new features but itself are independent from any organization.
MapLibre has 2 core projects: MapLibre GL JS for web and MapLibre Native for mobile and desktop. Both projects are a fork from Mapbox GL JS and Mapbox GL and created when Mapbox moved away from open source licensing and are now probably the go-to solution for permissive mapping libraries. The MapLibre team managed to get some big names like Amazon and Microsoft as sponsors on board, too.
MapLibre supports "Mapbox Vector Tiles" (MVT) but unless Mapbox with their Mapbox Style specification, they have their own fork called "MapLibre Style spec". Both are still widely compatible, only new additions are not.

This package josxha/flutter-maplibre uses the MapLibre SDKs under the hood but is not afiliated to the MapLibre organization.

So to answer your question, no you are not locked in to use Mapbox, even encoraged to use another tile provider. There is a list at: https://github.com/maplibre/awesome-maplibre?tab=readme-ov-file#maptile-providers

or can I use it with my own maps?

Yes, it's possible to host your own tiles with a tile server, too and you are free in what tile server you choose.

is it free and independent of other libraries for map styling and offline usage?

There are no restrictions in styling or offline usage by this package or the MapLibre SDKs. However, If you use a public tile server you need to comply with their tile usage policies. There are more restrict and there are more permissive policies out there. But If you host your own tiles, non of these apply eitherway.

What kind of performance can we expect in general?

In general we can expect performance that matches the official google maps package and the official mapbox package. All those packages use a native renderer written in C++. This package in particular makes use of some modern tweaks like interop with java through JNI and modern dart features. But its very hard to compare performance between them without running proper benchmarks.

However, it is certain that it has much better performance than vector tiles on flutter_map and even flutter_map in general. flutter_map and vector_map_tiles is 100% written in dart. This is great to support all plaforms but suffers in performance.

[mdmm13]

Thank you so much for sharing @josxha. Are you focusing your energy on this package now instead of flutter_map or both?

Also, won't flutter_gpu fix the performance issues flutter_map currently experiences?

[josxha]

Are you focusing your energy on this package now instead of flutter_map or both?

A big portion of my current energy is to push this package forward but I'm still helping on flutter_map, recently mostly on user support, though. In general, my efforts with the maplibre package does not necessarily have to mean ditching the other. I thought of creating a plugin that bridges the gap and makes it possible to either use this MapLibreMap as a layer in FlutterMap or vice versa.

Some proof of concept how this can look like. The polylon showcase from the flutter_map example app on top of maplibre:

Aufzeichnung_2024-09-19_001958_1.mp4

Also, won't flutter_gpu fix the performance issues flutter_map currently experiences?

I really hope it does eventually. At the moment, flutter_gpu is still in active development by the flutter team and only supports a limited amount of devices. It's hard to tell when this changes but let's estimate at least another year?
To tell the full story, platform views used by this package have limited platform support too. Windows and linux are currently missing and macos has only limited support. On the positive side, platform views exist for some time now and are used by a lot of packages, so they are more production-ready than flutter_gpu currently is.

Another thing worth mentioning is that flutter_map won't recieve those performance benefits automatically. Flutter recieved with flutter_gpu a new API for performant rendering using GLSL shaders. @kekland has put a lot of effort recently into creating a vector tile renderer that is based on the MapLibre style spec and shared this plans about creating a flutter_map plugin for it.
As far as I can tell, both our independent efforts have the goal to provide permissive vector map support for Flutter that is not vendor locked-in. Speaking of myself, I think It's really nice to have different approaches for a viable vector tiles solution on Flutter.

[josxha]

To share another aproach around this topic, @louwers recently mentioned some plans to add C interoperability to the MapLibre Native renderer:

[...] since we don't have a C FFI yet (which seems the way to go if you want to interface with native libraries directly with Kotlin Multiplatform). I think this will be developed over the course of the next year, since it is needed for getting the most performant implementation for Flutter possible, something Toyota has indicated interest in.

There are pros and cons if a flutter_gpu or a mbgl ffi solution is the better choice. In general it would be a big step for cross platform SDKs nethertheless.
But all these approaches will all take a lot of time and effort. Therefore, the goal for this maplibre package will be to create an easy to use and flutter friendly integration. (Compared to the maplibre_gl package which is relatively close to the MapLibre Android API with all it's builder classes and imperative API design.) Having this, we reduce the trouble for the user if we swap out MapLibre on Android and iOS with ffi bindings, flutter_gpu or any other upcoming solution.

• FFI Design Proposal maplibre/maplibre-native#1254
• Flutter bindings maplibre/maplibre-native#41
• MapLibre Native Compose Multiplatform Library maplibre/maplibre-native#2638

[kekland]

Btw, we've experimented with using dart:ffi and exposing native C bindings from the maplibre source in a separate project. We were able to get the renderer working, however, we ran into a lot of issues due to threading (Dart's UI thread vs the main thread). But, theoretically, in the next stable Flutter version it should be easier to get this to work, as the UI thread will be merged with the main thread (flutter/flutter#150525)