This is an open-source C++ implementation of deck.gl.
|Layer examples running on an iOS device|
LineLayer + ScatterplotLayer
Caveat: this is currently an in-progress effort that is targeting a minimal, proof-of-concept prototype. Even at completion, the initial
deck.gl-nativerelease is unlikely to meet the requirements of most applications. At this stage, asking for delivery dates and additional features without contributing to implementation or providing additional funding is unlikely to be helpful.
- Render to texture (not screen)
- Support deck.gl JSON API
- Layers: Only
- Tables: Only Apache Arrow tables will be supported, apps will need to use Arrow libraries if data is not already in Arrow format.
- loader support will be limited to CSV and line-delimited JSON.
- iOS only: will only be tested on iOS (no serious attempts will be done to make deck.gl-native work on other platforms).
Many features normally considered fundamental by deck.gl applications are not even being addressed at this stage
- No Render to screen
- No Transitions
- No Base map support (e.g. Mapbox integration)
- No Interactivity (event handling, picking etc)
- No Extensive layer catalog
- No Performance Optimizations
- iOS12+ is required when building for a device
- iOS13+ is required when building for a simulator, as
Metalis available on the simulator starting with iOS13
- Currently has to be built with bitcode disabled (under investigation)
- Tested and runs on Ubuntu Bionic
To get oriented on the deck.gl software architecture:
- deck.gl cross-platform architecture describes approaches to keeping multi-language implementations of deck.gl compatible (still a work-in-progress but gives a sense of the higher level direction).
API Design Principles and Cross-Platform Concerns
Currently the two main guidelines are:
- module and class parity Within reason, the same modules, classes (and often even filenames) are used in both implementations. This 1-to-1 mapping really helps developers move quickly between the two code bases.
Top-level API also includes exception-less counterparts for core functionality across the modules.
C++ Module Structure
The deck.gl-native code bases exposes a set of C++ "module header files" following a
||Platform/Compiler detection, assertions, logging and timers|
||Vectors and Matrices|
||Geospatial math for Web Mercator projection|
||A CSV table loader|
||A JSON table loader|
||Internal utilities for working with the WebGPU API (adaptions from the dawn repo)|
||GPU-based implementation of Arrow-like API|
||The core deck.gl classes:\
||The initial layer catalog|
||Classes for parsing (deck.gl) JSON into C++ objects|
modulepart corresponds to a submodule in that framework monorepo.
- Each of the modules is built as a separate library, in a format suitable for consumption on the OS it's being built for
All in-memory table processing is based on the Apache Arrow C++ API. This will be almost invisible to applications if they use the provided loaders, however for more advanced table processing applications may need to work directly with the Arrow API.
To get started with Arrow, useful resources might be:
CSV and JSON table loaders are provided as part of the deck.gl library. To support additional table formats, the envisioned approach is to implement additional "loaders" that load various formats and "convert" the loaded tables to Arrow representation.
Graphics Backend: dawn/WebGPU
deck.gl-native is being built on top of the C++ WebGPU API using the dawn framework.
The dawn framework is a compelling choice for deck.gl:
- The Dawn project has the ambition to provide backends on basically all platforms/rendering APIs of interest, including Vulkan, Metal, D3D12, and OpenGL. Ideally meaning that deck.gl-native itself will only have to implement a single backend, namely dawn.
Note that Dawn is still a work in progress (with different levels of support for different platforms - the prototype is only being tested on iOS) and there is some risk with this technology choice. However, given the momentum behind WebGPU in browsers, we feel that the prospects are currently looking good.
Supporting this Effort
This porting project is led by Unfolded, Inc, and currently relies on initial funding provided by a customer as well as external contributions. At this stage, this is not an fully or independenly resourced project. It only targets a proof-of-concept prototype, it does not have a maintenance plan and is not set up to address feature requests etc.
Our hope is to see this project quickly grow into a living part of the core deck.gl project. If this project reaches a sufficient level of completeness / critical mass, the ambition is to make this project part of the main deck.gl project and transfer it to an open governance setup.
Setting up a Development Environment
Development can be done on macOS which is the primary environment, or Linux, which is supported mainly for CI testing. (Windows is not a supported dev env.)
NOTE: Building using
gcc currently doesn't work, this is to be updated
Xcode (macOS only)
If you haven't already configured Xcode:
- Install Xcode
- Launch it
- accept the license agreement
sudo xcode-select -s /Applications/Xcode.app(Subsitute with path to your Xcode app if different).
brew install clang cmake clang-format lcov
brew install gcc cmake clang-format lcov
scripts/bootstrap.shto fetch the dependencies and perform setup.
bootstrap.shcan/should be called after pulling a branch to ensure environment is up to date
All the dependencies for macOS and Linux are bundled in a dependency repository that's being used as a submodule. Running
scripts/bootstrap.sh, among other things, fetches all the submodules. Alternatively, you can fetch them by running
git submodule update --init --recursive.
|Google Test||Testing framework|
|arrow||Columnar in-memory storage|
|dawn||C++ WebGPU implementation with a maturing list of backends for most platforms|
|shaderc||GLSL shader compilation|
|glfw||Portable library for creating OS windows to render graphics in, and handling events|
mkdir build cd build cmake .. make -j 16
To use different compilers, set the build options
CMAKE_CXX_COMPILER on the
cmake command line. There is a number of build scripts for different compilers available in
For Google Test formatted output, run
For CTest formatted output, run