deck.gl строится как модульная система поверх WebGL, в которой ключевым принципом является декларативное описание визуализации через слои (layers). Архитектура разделяется на несколько уровней: управление сценой, управление слоями, вычисление атрибутов, рендеринг через GPU и интеграция с внешними фреймворками.
В основе лежит разделение ответственности между ядром, слоями и рендерером. Ядро управляет состоянием приложения и жизненным циклом слоёв, слои определяют логику визуализации, а рендерер отвечает за взаимодействие с WebGL-контекстом.
Ключевой особенностью архитектуры является реактивная модель обновлений: изменение данных или свойств слоя не приводит к ручному пересозданию сцены, а вызывает инкрементальное обновление только затронутых частей графического пайплайна.
Центральным объектом выступает экземпляр Deck, который
объединяет:
Экземпляр Deck функционирует как оркестратор,
синхронизирующий данные и визуальное представление. Он не содержит
бизнес-логики визуализации, а делегирует её слоям.
Слой (Layer) — минимальная единица визуализации. Каждый слой описывает:
Слои проектируются как чистые функции от входных свойств. При изменении свойств слой пересоздаёт только необходимые GPU-ресурсы, минимизируя перерасход вычислений.
Существует иерархия слоёв:
CompositeLayer позволяет комбинировать несколько слоёв в единую логическую единицу, сохраняя при этом декларативность.
Каждый слой проходит строго определённые стадии:
Важный механизм — диффинг свойств. Система сравнивает предыдущие и новые параметры слоя, определяя, какие части требуют пересчёта.
Если изменяются только визуальные параметры (например, цвет), пересчёт геометрии не выполняется. Если меняются данные — пересчитываются атрибуты.
Внутри системы используется концепция attribute manager. Он отвечает за хранение и обновление буферов GPU.
Основные принципы:
Каждый слой описывает набор атрибутов, например:
AttributeManager решает, когда пересоздавать буферы и когда можно переиспользовать существующие.
Рендеринг в deck.gl строится как последовательность стадий:
Система оптимизирована для минимизации количества draw calls, что критично для больших наборов данных.
Архитектура включает слой абстракции над камерой — View system.
Основные сущности:
Поддерживаются различные типы представлений:
Каждое представление влияет на матрицы трансформации и способ интерпретации координат.
Вся система координат строится вокруг цепочки трансформаций:
Deck.gl автоматически управляет матрицами:
Обновление камеры приводит к пересчёту viewport и всех зависимых слоёв, но не обязательно к пересборке данных.
Одним из ключевых механизмов является система флагов обновления. Каждый слой имеет набор состояний:
Эти флаги позволяют точно определить, какие части pipeline необходимо пересчитать.
Инвалидация распространяется по зависимостям: изменение одного слоя может повлиять на composite-слои, но не затрагивает независимые слои.
Низкоуровневый доступ к WebGL скрыт за абстракциями:
Модель (Model) представляет собой связку:
Shader modules позволяют переиспользовать GLSL-код между слоями, избегая дублирования логики освещения, проекций и трансформаций.
CompositeLayer реализует механизм вложенности:
Это позволяет строить сложные визуализации из простых примитивов без нарушения архитектурной целостности.
Пример логики:
Поверх ядра существует интеграционный слой, связывающий систему с компонентной моделью React.
Основные механизмы:
React-компонент выступает как оболочка над экземпляром Deck, обеспечивая реактивную модель обновлений без ручного управления рендерингом.
Архитектура учитывает асинхронную природу работы с большими данными:
Система стремится минимизировать блокировки main thread, делегируя тяжёлые операции Web Workers (в некоторых расширениях).
Состояние сцены включает:
Состояние не хранится централизованно в едином сторе, а распределено между Deck, слоями и менеджерами ресурсов. Это снижает связность и повышает масштабируемость архитектуры.
Каждый цикл рендеринга представляет собой повторяющийся процесс:
Цикл оптимизирован так, чтобы пропускать стадии при отсутствии изменений, что критично для интерактивных визуализаций.
Архитектура рассчитана на работу с:
Масштабирование достигается за счёт:
Система остаётся стабильной при росте объёма данных благодаря строгому разделению уровней ответственности и отсутствию глобальных мутаций состояния.