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

fix: typos (#4202)

Browse Source 
Co-authored-by: Bart Louwers <bart@emeel.net>
This commit is contained in:
Mike Taves
2026-07-14 03:08:27 +12:00
committed by GitHub
parent 9d53ac53a6
commit fba652eb72
76 changed files with 100 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
design-proposals/2022-09-02-kotlin.md
View File

@@ -9,7 +9,7 @@ The argument for Kotlin over Java is typically along the lines of Kotlin being a
Kotlin seems like a natural successor language to java, because it brings some advantages with no real downsides. It has full interoperability allowing us to port files 1-1.
There are also intersting features being added to the language that we can explore in the future if we decide to invest in kotlin competence now - such as [Kotlin Multiplatform](https://kotlinlang.org/docs/multiplatform.html#full-stack-web-applications) for cross-platform compilation.
There are also interesting features being added to the language that we can explore in the future if we decide to invest in kotlin competence now - such as [Kotlin Multiplatform](https://kotlinlang.org/docs/multiplatform.html#full-stack-web-applications) for cross-platform compilation.
## Proposed Change

4
design-proposals/2022-11-29-metal-port.md
View File

@@ -196,7 +196,7 @@ If you thought real time rendering was mostly about triangles, I have some bad n
The boring way is to allocate Buffers and stick your geometry, indices, textures, uniforms, car keys, manifesto, and texture coordinates in them. They're just memory. You ask for how much you want, you get a handle, you copy what you need into place. You fix whatever buffer overruns you created.
Metal isn't fussy about a buffer containing vertices vs. indices vs. uniforms. Mostly. So you build a little buffer management infrastructure and alway use it.
Metal isn't fussy about a buffer containing vertices vs. indices vs. uniforms. Mostly. So you build a little buffer management infrastructure and always use it.
The nice thing about Buffer allocation in Metal is it can be easily done from any thread. The bad thing is all those little bits of memory are time consuming to track and control, just like in any system. Thus there is a better way.
@@ -329,7 +329,7 @@ Typically bottlenecks are where the main CPU is waiting on something it shouldn'
MapLibre Native makes some use of threads, but not as much as it should. With OpenGL it's not using shared contexts, though it does a lot of work in the Layers to prep for the GL work that has to be done on the main thread. So it's not terrible, but it obviously could be better.
Mobile devices, even the really cheap ones, now have a lot of CPU cores and a lot of opportunity for work to be done off the main thread. Maps have an embarassing amount of high level parallelism. It's worth periodically analyzing the performance to see what might be updated for data loading.
Mobile devices, even the really cheap ones, now have a lot of CPU cores and a lot of opportunity for work to be done off the main thread. Maps have an embarrassing amount of high level parallelism. It's worth periodically analyzing the performance to see what might be updated for data loading.
The benefits are faster loading, lower latency, better responsiveness to the user.

4
design-proposals/2023-06-17-android-annotations.md
View File

@@ -16,7 +16,7 @@ The following ideas drive the design proposal for the improved API.
* (G1 **`maplibre-native`**) The annotation API should be a part of `maplibre-native`.
* (G2 **frictionless migration**) The new API should create as few friction as necessary for existing users of the annotations plugin during migrations.
* (G3 **Kotlin-first**) The API should facilitate Kotlin langauge features where appropriate.
* (G3 **Kotlin-first**) The API should facilitate Kotlin language features where appropriate.
* (G4 **power**) The annotations API should be as powereful as it was before. No functionality should be lost.
* (G5 **learnability**) At the same time, it should have a high learnability, such that new users find their way around the API with ease.
* (G6 **ease**) The API should be user-friendly and easy to use.
@@ -113,7 +113,7 @@ The `setUsedDataDrivenProperties` mechanism should check for variations to the d
The annotations API currently uses code generation to generate the annotation objects. This should no longer be done in the future for the following reasons.
* Code generation incentivises non-specific, flat APIs – even where hiearchical objects or other specific constructs make more sense.
* Code generation incentivises non-specific, flat APIs – even where hierarchical objects or other specific constructs make more sense.
* In a similar way, it makes it harder to assign documentation to specific method →(G5 **learnability**). The current generated docs don't read like they were written with the Android implementation in mind, because they are copied from the spec.
* When switching to Kotlin and when removing the `*Options` classes (G3 **Kotlin-first**), boilerplate code is reduced by a significant amount.

4
design-proposals/2025-05-08-plugin-layers.md
View File

@@ -6,7 +6,7 @@ This project is to add the ability to "register" additional layer types at runti
## Proposed Change
For the initial implemention, the following functionality is proposed:
For the initial implementation, the following functionality is proposed:
* At the platform level, be able to register a plug-in layer that is then parseable by the style parser
* The plug-in layer will be limited to simple rendering (via handing off the rendering context to the plug-in layer) and will not include the ability to define drawables/etc
@@ -18,7 +18,7 @@ Future features:
* Placeholder for ideas that could be implemented in the future
## Example IOS Utilization
An example implemention is shown in the PR: https://github.com/maplibre/maplibre-native/pull/3430
An example implementation is shown in the PR: https://github.com/maplibre/maplibre-native/pull/3430
The platform/darwin/app/PluginLayerExampleMetalRendering.h/mm class shows how the layer manages it's own rendering and how properties from the style are passed to it. In platform/ios/app/MBXViewController.mm there's a single line where the plug-in layer class is registered with the map view
```
[self.mapView addPluginLayerType:[PluginLayerExampleMetalRendering class]];