Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

This is an open-source C++ implementation of

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 release 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 JSON API
  • Layers: Only ScatterplotLayer, LineLayer, SolidPolygonLayer
  • 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 work on other platforms).

Not Planned

Many features normally considered fundamental by 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
  • etc

Supported Platforms


  • iOS12+ is required when building for a device
  • iOS13+ is required when building for a simulator, as Metal is available on the simulator starting with iOS13
  • Currently has to be built with bitcode disabled (under investigation)


  • macOS10.14+


  • Tested and runs on Ubuntu Bionic

Software Architecture

To get oriented on the software architecture:

  • Technical Deep-Dive is a good initial read. Written for the JavaScript version, however most concepts apply directly to the C++ port as well.
  • cross-platform architecture describes approaches to keeping multi-language implementations of compatible (still a work-in-progress but gives a sense of the higher level direction).

API Design Principles and Cross-Platform Concerns

A primary concern for the port, especially once it matures, is how to keep it develop in sync with the various implementations and variants of the API, such as the core JavaScript codebase, the pydeck Python API etc.

Currently the two main guidelines are:

  • JSON parity The JSON API (See e.g. playground) is the "common API" that will be supported by both the JavaScript and C++ implementations of This help ensure that both the C++ and JavaScript renderers evolve in sync, always providing compatible features (when their layer catalogs overlap etc).
  • 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.

Beyond the above rules, it is certainly acceptable C++ and JavaScript APIs to diverge, as long as it makes sense, to ensure they are both natural to use for programmers with backgrounds in the respective programming language. (E.g. functional style UI programming is common in the JS community while C++ programmers on the balance are likely favor a more imperative API style).

Top-level API also includes exception-less counterparts for core functionality across the modules.

C++ Module Structure

The code bases exposes a set of C++ "module header files" following a <framework>/<module>.h structure.

Module Description Platform/Compiler detection, assertions, logging and timers Vectors and Matrices Geospatial math for Web Mercator projection A CSV table loader A JSON table loader Model, AnimationLoop etc implemented on dawn API Internal utilities for working with the WebGPU API (adaptions from the dawn repo) GPU-based implementation of Arrow-like API The core classes:\ Deck, Layer, View, etc. The initial layer catalog Classes for parsing ( JSON into C++ objects


  • The framework part of the C++ module header file name corresponds on the JavaScript side to a framework from the framework suite, and the module part 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

Apache Arrow

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 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 is being built on top of the C++ WebGPU API using the dawn framework.

The dawn framework is a compelling choice for

  • The JavaScript version of will inevitably move from WebGL to WebGPU, so having both C++ and JavaScript work against a common 3D API will signficantly increase the ease of aligning the JavaScript and C++ code bases.
  • 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 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 project. If this project reaches a sufficient level of completeness / critical mass, the ambition is to make this project part of the main 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
  • Run sudo xcode-select -s /Applications/ (Subsitute with path to your Xcode app if different).


For macOS:

brew install clang cmake clang-format lcov


For macOS:

brew install gcc cmake clang-format lcov
  • scripts/ to fetch the dependencies and perform setup. can/should be called after pulling a branch to ensure environment is up to date
  • scripts/build-clang or scripts/build-gcc to build


All the dependencies for macOS and Linux are bundled in a dependency repository that's being used as a submodule. Running scripts/, among other things, fetches all the submodules. Alternatively, you can fetch them by running git submodule update --init --recursive.

Dependency Description
Google Test Testing framework
jsoncpp JSON parser
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_C_COMPILER and CMAKE_CXX_COMPILER on the cmake command line. There is a number of build scripts for different compilers available in scripts directory.


For Google Test formatted output, run ./deckgl-bundle-tests. For CTest formatted output, run ctest.