tei/MapLibreParticleLab
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Rename MapLibre GL Native -> MapLibre Native (#1075)

Browse Source
This commit is contained in:
Birk Skyum
2023-04-26 20:19:52 +02:00
committed by GitHub
parent 20c43c7cc9
commit 82f3f971f7
47 changed files with 133 additions and 133 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
ARCHITECTURE.md
View File

@@ -1,8 +1,8 @@
This document aims to outline at a high level the various parts that make up MapLibre GL Native and how they work together.
This document aims to outline at a high level the various parts that make up MapLibre Native and how they work together.
# Repository structure
MapLibre GL Native uses a monolithic repository that houses both core C++ code and code that wraps the C++ core with SDKs for Android, iOS, macOS, Node.js, and Qt. A "monorepo" allows us to:
MapLibre Native uses a monolithic repository that houses both core C++ code and code that wraps the C++ core with SDKs for Android, iOS, macOS, Node.js, and Qt. A "monorepo" allows us to:
* Make changes to the core API and SDKs simultaneously, ensuring no platform falls behind.
* Ensure that core changes do not inadvertently break SDK tests.
@@ -38,7 +38,7 @@ Code and build scripts belonging to platform SDKs are contained in the `platform
# Build system
The MapLibre GL Native build system uses a variety of tools.
The MapLibre Native build system uses a variety of tools.
## Make
@@ -50,17 +50,17 @@ Git submodules are used to pull in several dependencies: mason (see below) and s
## npm
npm is a package manager for Node.js. MapLibre GL Native uses it to pull in several development dependencies that happen to be packaged as node modules -- mainly for testing needs.
npm is a package manager for Node.js. MapLibre Native uses it to pull in several development dependencies that happen to be packaged as node modules -- mainly for testing needs.
## Mason
[Mason](https://github.com/mapbox/mason) is Mapbox's own cross platform C/C++ package manager. MapLibre GL Native uses mason packages as a source of precompiled binaries for third-party dependencies such as Boost, RapidJSON, and SQLite, and Mapbox's own C++ modules such as [earcut.hpp](https://github.com/mapbox/earcut.hpp) and [geojson-vt-cpp](https://github.com/mapbox/geojson-vt-cpp). It is also used to obtain a toolchain for Android platform cross-compiliation.
[Mason](https://github.com/mapbox/mason) is Mapbox's own cross platform C/C++ package manager. MapLibre Native uses mason packages as a source of precompiled binaries for third-party dependencies such as Boost, RapidJSON, and SQLite, and Mapbox's own C++ modules such as [earcut.hpp](https://github.com/mapbox/earcut.hpp) and [geojson-vt-cpp](https://github.com/mapbox/geojson-vt-cpp). It is also used to obtain a toolchain for Android platform cross-compiliation.
We track mason dependencies for a given platform in the file `platform/<platform>/scripts/configure.sh`. The `configure` script at the root handles sourcing this file during the build, running the appropriate mason commands, and writing configuration settings for the subsequent build to a `config.gypi` in the build output directory.
## gyp
[gyp](https://gyp.gsrc.io/) is a build system originally created for Chromium and since adopted by Node.js. In MapLibre GL Native it's used to build the core C++ static library, the Node.js platform module, and the shared JNI module for Android.
[gyp](https://gyp.gsrc.io/) is a build system originally created for Chromium and since adopted by Node.js. In MapLibre Native it's used to build the core C++ static library, the Node.js platform module, and the shared JNI module for Android.
## Platform-specific subsystems
@@ -77,9 +77,9 @@ See the relevant platform-specific `README.md` / `INSTALL.md` for details.
## Map
## Style
The "Style" component of MapLibre GL Native contains an implementation of the [Mapbox Style Specification](https://www.mapbox.com/mapbox-gl-style-spec/), defining what data to draw, the order to draw it in, and how to style the data when drawing it.
The "Style" component of MapLibre Native contains an implementation of the [Mapbox Style Specification](https://www.mapbox.com/mapbox-gl-style-spec/), defining what data to draw, the order to draw it in, and how to style the data when drawing it.
In addition to supporting styles loaded from a URL, MapLibre GL Native includes a runtime styling API, which allows users to dynamically modify the current style: add and remove layers, modify layer properties, and so on. As appropriate for a C++ API, the runtime styling API API is _strongly typed_: there are subclasses for each layer type, with correctly-typed accessors for each style property. This results in a large API surface area. Fortunately, this is automated, by generating the API – and the regular portion of the implementation – from the style specification.
In addition to supporting styles loaded from a URL, MapLibre Native includes a runtime styling API, which allows users to dynamically modify the current style: add and remove layers, modify layer properties, and so on. As appropriate for a C++ API, the runtime styling API API is _strongly typed_: there are subclasses for each layer type, with correctly-typed accessors for each style property. This results in a large API surface area. Fortunately, this is automated, by generating the API – and the regular portion of the implementation – from the style specification.
The layers API makes a distinction between public API and internal implementation using [the `Impl` idiom](https://github.com/mapbox/mapbox-gl-native/issues/3254) seen elsewhere in the codebase. Here, it takes the form of parallel class hierarchies:
@@ -132,7 +132,7 @@ One final benefit of this approach of diffing immutable objects: we get "smart"
# Threading
At runtime, MapLibre GL Native uses the following threads:
At runtime, MapLibre Native uses the following threads:
* The "main thread" (or other thread on which a `Map` object is created) handles direct `Map` API requests, owns the active `Style` and its associated objects, and renders the map. Since this thread is usually dispatching events triggered by user input, it's important that these duties not require significant computation or perform blocking I/O that would cause UI jank or hangs.
* Many of the tasks that require significant computation are associated with layout and styling of map features: parsing vector tiles, computing text layout, and generating data buffers to be consumed by OpenGL. This work happens on "worker threads" that are spawned by the main thread, four per `Style` object. The `Style` and its associated objects handle dispatching tasks to the workers, typically on a tile-by-tile basis.