Kepler.gl построен поверх WebGL-стека deck.gl, где каждая 3D-сцена формируется через слой (layer) с инстансированным рендерингом. Основная нагрузка в 3D-режиме возникает на трёх уровнях: геометрия, шейдеры и обновления состояния.
Геометрическая часть включает отрисовку миллионов точек, экструдированных полигонов, 3D-гексагонов и инстансированных объектов. Шейдерная нагрузка усиливается при использовании освещения, теней и наклонной камеры. Состояние приложения (viewport, filters, dataset) может приводить к повторной инициализации GPU-буферов при неправильной организации обновлений.
Основной принцип оптимизации 3D-рендеринга заключается в снижении количества активных инстансов, поступающих в WebGL-пайплайн.
Ключевые техники:
Особенно критичен переход от PointLayer к агрегированным
слоям при данных выше сотен тысяч объектов. В 3D-режиме каждый
дополнительный инстанс увеличивает нагрузку не линейно, а через рост
работы vertex shader и fragment shader.
Hexagon и grid aggregation являются ключевыми инструментами стабилизации производительности. Вместо отрисовки отдельных точек выполняется предварительная свёртка данных.
Типичный эффект:
При работе с 3D extrusion особенно важно ограничивать
elevationScale, так как высокие значения увеличивают
визуальную сложность сцены и нагрузку на пиксельные шейдеры.
LOD-подход в Kepler.gl реализуется через сочетание zoom-dependent rendering и фильтрации данных.
Основные механизмы:
Для экструдированных объектов критично ограничение количества вершин. Полигональные здания с высокой детализацией резко увеличивают стоимость rasterization stage при наклонённой камере.
Основной источник лишних перерисовок — частые изменения состояния
visState.
Оптимизационные подходы:
В архитектуре Kepler.gl любые изменения конфигурации слоёв могут триггерить пересоздание deck.gl layers, что приводит к повторной загрузке GPU буферов.
Интеграция Kepler.gl с React требует строгого контроля ререндеров контейнера.
Ключевые методы:
useMemo для конфигураций слоёвconfig,
filters, layersКаждый новый reference в props может привести к полной реконструкции deck.gl scenegraph.
В 3D-режиме основная нагрузка приходится на GPU:
Практические оптимизации:
opacity слоёв вместо сложных
blend-режимовТакже критично уменьшение overdraw — количества перекрывающихся пикселей, особенно при высоком pitch камеры.
Каждое изменение камеры (zoom, pitch, bearing) вызывает перерасчёт матрицы проекции и потенциальный redraw всех слоёв.
Оптимизация:
Наклон камеры напрямую увеличивает количество пикселей, обрабатываемых fragment shader, что критично для экструдированных слоёв.
При объёмах данных в миллионы записей основная стратегия — перенос вычислений из браузера:
JSON становится узким местом из-за парсинга и GC pressure. Более эффективны TypedArrays и precomputed buffers.
deck.gl использует instancing для большинства слоёв, однако эффективность зависит от структуры данных.
Оптимизационные принципы:
Снижение draw calls имеет больший эффект, чем локальные оптимизации шейдеров.
Фильтры в Kepler.gl часто становятся причиной деградации производительности при неправильной реализации.
Ключевые подходы:
Особенно затратны временные фильтры (time filters), которые требуют пересчёта наборов данных при каждом изменении диапазона.
Экструдированные полигоны являются одним из самых тяжёлых типов визуализации.
Методы оптимизации:
Геометрическая сложность зданий линейно увеличивает нагрузку на vertex shader и может приводить к bottleneck даже при небольшом количестве объектов.
Стабильность производительности достигается за счёт повторного использования промежуточных результатов:
При правильной организации кеша уменьшается количество CPU-bound операций перед отправкой данных в GPU.
3D-визуализация всегда требует компромисса между детализацией и производительностью:
Стабильный рендеринг достигается через многоуровневую деградацию качества: от точек к агрегатам, от сложных полигонов к упрощённым формам, от динамического освещения к статическому цвету.