Help & Opinions Needed: Clean MapLibre Implementation in Compose Multiplatform

[jershell]

To get MapLibre running on Compose Desktop & WASM, we started a clean implementation using Compose Multiplatform. After making some progress, we’ve realized that—even with MapLibre’s excellent documentation—a full clean implementation is a pretty massive task that takes a lot of time and effort. Right now, we have a working prototype (I’ve hidden it under a spoiler). Also debug app

I’m writing here to ask for your thoughts on the future of this effort 😊 Is there any way to organize some collaboration, so we could join forces and achieve a full implementation together? Or do you think it’s not worth pursuing? Any opinions or advice would be greatly appreciated! 🙏

Screenshots(StreetV2 style)

Screenshots(Other styles)

Symbols Layout

The result is shown(BIG GIF) in the screenshot below.

Screenshots(collision detection debug)

[sargunv]

Oh wow, is this a reimplementation of a map renderer on the Skia canvas instead of using MapLibre Native? That's really impressive!

I’m writing here to ask for your thoughts on the future of this effort 😊 Is there any way to organize some collaboration, so we could join forces and achieve a full implementation together? Or do you think it’s not worth pursuing? Any opinions or advice would be greatly appreciated! 🙏

Well, I've thought about building something similar instead of pursuing #218, but decided not to, because while both are gargantuan efforts, I felt graphics rendering is so far outside my skillset that I'd definitely burn out if I went at it alone 😅.

(by the way, @westnordost, we even talked about such a project last month)

Thinking about it some more, I think such a project would never fully replace a MapLibre Native / GL JS wrapper though, because Skia is a 2D graphics library, and MapLibre has some 3D features:

• globe view and 3d hillshading on JS
• fill extrusion layer
• soon: plugin layers with arbitrary rendering logic

But on the other hand, a MapLibre Native/JS wrapper will never fully work properly with Compose, because of issues like this:

• Alpha transitions don't work properly with the map on Android #15
• The camera follow demo does not stop following on compass ornament or double tap zoom #77
• The native scale bar on Android does not update its size when the screen size changes #126
• The map on desktop is always on top of Compose UI #184
• The map on web is always on top of Compose UI #210

So yeah, I'd say it's worth pursuing a Skia renderer, if you have the motivation to pursue it. Apps that only need the 2D features would probably be more robust with the Skia renderer if it's completed.

Is there any way to organize some collaboration, so we could join forces and achieve a full implementation together?

I think collaboration is possible. A Compose Multiplatform implementation for MapLibre really solves two high level problems:

• Compose-idiomatic map styling and interactivity
  • like @Composable sources and layers
  • but also proper support for TextUnit and other Compose data types on the styling API
• Cross platform map rendering

It'd be great if we solve the top half, the Kotlin and Compose idiomatic map styling API, just once instead of twice.

With maplibre-compose, these two problem layers are somewhat coupled together in implementation, but it doesn't need to be that way. I've already thought about needing some decoupling so the "rendering engine" can be swapped out depending on the needs of the app. For example:

• MapLibre Native has implementations on both OpenGL and Vulkan for non-Apple platforms (and only Metal on Apple, I think?)
• MapLibre GL JS tends to support new features sooner than MapLibre Native, so some non-web apps may prefer a webview renderer approach
• Someday, I hope to support maplibre-rs
• And now, this Skia Canvas based renderer

So, I've been thinking about some sort of API where there's an interface for the "engine" of the map, and it's interchangeable with different implementations available on various platforms. If you've used Ktor, you might be familiar with how you initialize an HTTP client with HttpClient(engine), where engine can be CIO, or Darwin, or OkHttp, or Curl, and so on. Some are multiplatform, others are platform specific, some have more features, some fewer, but it all gets wrapped under one HttpClient API. Something similar for MapLibre Compose would be interesting.

So, what does that mean for collaboration? Well if on our side we work on decoupling the API from the rendering engine, and on your side the focus is on just getting map functionality implemented with a barebones API without worrying too much about API ergonomics or interactivity, then in the end we could have a full implementation with a single API across MapLibre Native, JS, and Skia.

If all that sounds reasonable to you, then we should probably talk about where the API boundaries should be: what's a responsibility of the "engine" vs of the API? For example, I'd propose that camera state and gestures should be hoisted up to the API, but tile management kept inside the engine.

And in the short term, well we already have one sufficiently decoupled module: maplibre-compose-expressions is a full implementation of the MapLibre expression spec as a Kotlin DSL. It even has support for Compose types like referencing images with Painter or automatic text scaling using TextUnit. So, you can already save a ton of work implementing all that by pulling in that library.

[sargunv]

And by the way, if you're not there already, you should join the #maplibre-compose channel on the OSMUS Slack