Integrate with Maplibre Native Core

[sargunv]

The MapLibre Android and MapLibre iOS SDKs are convenient, but they do a lot of work and hide some internals that would be better for us to implement in compose and KMP. Additionally, there's no such SDK for desktop platforms, and the current web view solution for desktop is problematic.

If we need to build on the C++ core for desktop, it's good opportunity to do the same for all three native platforms and move more code (gestures, styling, controls, etc) all into common code. For web, we can then disable anything not related to rendering, display under the Compose canvas, and operate with all the same common controls and gestures as native.

List of issues that would be solved or aided with this

• Reducing platform specific differences:
  • much of API redesign for platform specific behavior #217
  • Support bounding the camera #20
• Better desktop platform:
  • Desktop APIs that return data (callbacks, query functions, camera state) can't easily be implemented with the synchronous API #219
  • Desktop (webview) map doesn't scale properly on Linux (Fedora 41, wayland) #239
• Reimplementing controls solves all of:
  • 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 native scale bar on android always grows to the right, even if aligned to the right #124
  • Indirectly: The map on web is always on top of Compose UI #210
  • Though of course most of this can be done just by disabling the existing SDK controls and/or PRing improvements upstream.

Alternative

Why not just keep using the iOS and Android SDKs and just disable SDK ornaments, gestures, and animations?

• We'd still need to integrate with the native core on desktop (unless we want to keep the web view around)
• Android/iOS/Desktop would all need dedicated implementations of the whole source/layer glue code, only to each integrate with the same native core underneath

Downsides of integrating with the native core

• Desktop becomes up to six platforms instead of the one (JVM) now:
  • Linux, macOS, and Windows, each on x64 and ARM. Though we won't necessarily need to support them all (macOS x64 is being phased out, Windows on ARM is still pretty niche)
  • Upstream seems to support amd64 and arm64 on Linux and macOS, but just amd64 on Windows
  • Need to figure out packaging for that
    • bundling ~6 native libraries in a "fat" universal jar isn't ideal, though okay for a first pass if it works
• Need to maintain redundant code for Android / iOS integration that already exists upstream
  • TBD: how much exactly?

Kotlin to C++ integration requirements

• On Android and Desktop, we can do JNI to C++
  • Or https://github.com/jnr/jnr-ffi for simpler integration to C bindings
• Kotlin Native can interop with C or ObjC bindings (also Swift with @objc)

So the most straightforward solution is probably to write C bindings for MLN and use it on both sides.

Platform integration specifics

(mostly guesswork here as I'm still learning about the native core)

Android

Android will render into a Surface. The Android SDK today renders to a GLSurfaceView or a TextureView, but if we're reimplementing this we should ideally be agnostic to where the Surface comes from so we can use it with Jetpack Compose's AndroidExternalSurface and AndroidEmbeddedExternalSurface composables.

We'll want to provide some implementation for both OpenGL and Vulkan; unsure how that'll be packaged exactly.

iOS

I've done no research here, but presumably we can do it with the Metal renderer the same way the iOS SDK currently does (probably MKTView?).

Desktop

We need to embed the native OpenGL, Vulkan, and/or Metal renderer into a Swing panel within Compose. Perhaps with JOGL for OpenGL?

Doing some research on whether anyone has done this in Compose yet, and I haven't found anything (just this bare YouTrack)

[sargunv]

Collecting some resources for later:

• https://github.com/LWJGLX/lwjgl3-awt/ looks like a nice helper to get an OpenGL or Vulkan render surface into Swing for Compose SwingPanel.
• https://jogamp.org/jogl/www/ is another option, just for OpenGL
• Or just skip the helper libraries and use Java AWT Native Interface directly? https://en.wikipedia.org/wiki/Java_AWT_Native_Interface
  • more info here: https://docs.oracle.com/en/java/javase/22/docs/specs/AWT_Native_Interface.html
• This article talks about creating a native Metal surface with MKTView and using it with AWT

[sargunv]

I have a functioning example of OpenGL within AWT: https://github.com/sargunv/awt-opengl-sample/blob/main/app/src/main/kotlin/org/example/App.kt

[westnordost]

Though we won't necessarily need to support them all (macOS x64 is being phased out [...]

😉