Оптимизация графики в Voximplant Kit

    Что делать, если сценарий крутой и сложный, но из-за этого начинает тормозить? Данным вопросом задались наши разработчики Voximplant Kit и придумали функцию оптимизации. Продолжая серию обновлений Кита, расскажем, как оптимизация заставила большие сценарии летать и с какими проблемами мы столкнулись в процессе её создания.

    Почему надо оптимизировать

    Многим знакома проблема производительности, вызванная наличием слишком большого количества элементов на странице. Что это значит? В нашем случае чем больше элементов в сценарии Voximplant Kit, тем больше это влияет на скорость визуализации перемещения блоков по холсту (всех вместе и по отдельности), а также на скорость визуализации перемещения и масштабирования самого холста. 

    Мы рассмотрели разные варианты и пришли к выводу, что в качестве решения отлично подойдёт CSS свойство will-change, позволяющее заранее проинформировать браузер об изменениях, которые могут быть применены к элементу. Благодаря этому свойству можно настроить оптимизацию до начала изменений во избежание затрат на запуск операций, негативно влияющих на отзывчивость страницы.

    Однако трансформации, связанные с перемещением и масштабированием холста, применяются в используемой нами библиотеке JointJS к дочерней группе элементов SVG, а не ко всему холсту. Поэтому сначала мы не могли переложить вычисления на видеокарту, браузеры игнорировали это свойство и перерисовывали все элементы группы на каждое движение, что вызывало задержку.

    <svg ... > <!-- Холст -->
      <g transform="matrix(1,0,0,1,224,444)"> <!-- Группа элементов внутри svg -->
        <rect>
        <rect>

    Реализация

    У наших разработчиков появилась идея обернуть SVG в div-элемент, чтобы применять все трансформации сначала к нему, а затем при необходимости к самому SVG-элементу с холстом. После того, как трансформации стали применяться к <div>, мы смогли использовать will-change: transform для их отслеживания:

    <div> <!-- div-обёртка, к которой применяется оптимизация -->
      <svg ... > <!-- Холст -->
        <g> <!-- Группа элементов внутри svg -->
          <rect>
          <rect>

    Но появилась ещё одна проблема – использование will-change инициирует создание нового слоя, и чем больше ширина и высота элемента, к которому это св-во применяется, тем больше расходуется оперативной памяти для хранения слоя. Справиться с этим помогло уменьшение масштаба SVG в 10 раз. Так, например, при масштабе холста = 200% для слоя с will-change требовалось 300 мегабайт оперативки , а после уменьшения масштаба стало нужно всего около 3 мегабайт.

    Чтобы это осуществить, выставляем параметр zoom = 0.1 и подключаем к работе методtransformToCenterViewport, после чего применяем те же трансформации к div-элементу:

    if (isPerfMode) {
      this.el.classList.add('perf-mode');
      // Меняем масштаб перед включением performance mode
      const prevScale = this._viewportMatrix.a;
      const point = this.getViewPortCenter();
      const zoom = 0.1;
         
      // Уменьшаем исходный svg, чтобы will-change тратил меньше оперативной памяти
      this.transformToCenterViewport(point, zoom, true, false, true);
      this.initScale = this._viewportMatrix.a;
      this.createMatrix();   
      this.isPerfMode = true;
         
      // Применяем трансформации к элементу-обертке
      this.startPerformance();
      this.transformToCenterViewport(point, prevScale, false, false, true);
    }

    Т.к. при переходе в режим оптимизации мы уменьшаем SVG, холст становится очень маленьким и неудобным для работы. Чтобы это исправить, применим обратное масштабирование непосредственно к div-элементу:

    public startPerformance(force = false) {
      ...
      this.isPerformance = true;
      
      // Получаем размер области с блоками и отступ от левого угла вьюпорта
      const { x, y, width, height } = this.layers.getBBox();
      const initScale = this.initScale;
      
      // Ширина и высота для обёртки и смещение по оси x и y для области с блоками
      const wrapW = Math.floor(width * initScale) + 2;
      const wrapH = Math.floor(height * initScale) + 2;
      const layerX = -x * initScale;
      const layerY = -y * initScale;
      
      // this.wrapMatrix - матрица div-элемента с холстом
      this.wrapMatrix.e = +(this._viewportMatrix.e + x * this._viewportMatrix.a);
      this.wrapMatrix.f = +(this._viewportMatrix.f + y * this._viewportMatrix.d);
      this.svgWrapper.style.width = wrapW + 'px';
      this.svgWrapper.style.height = wrapH + 'px';
      this.svgWrapper.style.transform = this.wrapMatrix.toString();
      this.svgWrapper.style.willChange = 'transform';
      this.layers.style.transform = `matrix(${initScale},0,0,${initScale},${layerX} ,${layerY} )`;
    }

    Со скоростью мы разобрались, но на этом сложности не закончились: при уменьшении масштаба холста стали пропадать детали изображения, а при увеличении оно стало размываться. На решение этой проблемы натолкнула статья о повторном растрировании композитных слоев при изменении масштаба

    После завершения масштабирования (событие о скролле), св-во will-change удаляется на 0.1 секунды и затем устанавливается заново. Это заставляет браузер повторно растрировать слой, возвращая пропавшие детали изображения:

    // Добавляем 3d трансформацию, чтобы слой не был удален
    this.svgWrapper.style.transform = this.wrapMatrix.toString() + ' translateZ(0)';
    this.transformFrameId = requestAnimationFrame(() => {
      // Устанавливаем св-во will-change для применения в следующем кадре
      this.svgWrapper.style.willChange = '';
      this.transformFrameId = requestAnimationFrame(() => {
        this.svgWrapper.style.willChange = 'transform';
        this.svgWrapper.style.transform = this.wrapMatrix.toString();
      });
    });

    Осталось внести последний фикс – всегда отображать перемещаемый блок поверх других. В JointJS для перемещения блоков и линков по оси Z существуют методы toFront и toBack (аналог z-index в HTML). Принцип их работы заключается в сортировке элементов и перерисовке блоков и линков, это вызывает задержки.

    Наши разработчики придумали следующее: блок, с которым мы взаимодействуем, временно ставится в конец дерева элементов внутри SVG (элемент с самым высоким z-index находится в конце списка) на событие mousedown, а затем возвращается на прежнее место на событие mouseup.

    Принцип работы

    Режим оптимизации можно протестировать во всех браузерах на основе Chromium (Chrome, Opera, Edge, Yandex Browser и т.п.), а также в браузере Safari. Для сценариев, содержащих от 50 блоков, функция включается автоматически. Самостоятельно включить или отключить её можно, перейдя в меню настроек сценария в правом верхнем углу:

    Как только оптимизация будет включена или выключена, в верхней части окна со сценарием появится уведомление:

    Ниже для сравнения представлены 2 гифки, демонстрирующие работу в редакторе с выключенным и включенным режимом оптимизации. Но поскольку всегда интереснее потестить самому, смело переходим в свой сценарий Voximplant Kit или, если ещё нет аккаунта, – на страницу регистрации

    Без оптимизации работа с холстом и его элементами выглядит примерно так (на разных компьютерах с разными мощностями результат может отличаться):

    Подключаем оптимизацию и вуаля!

    В итоге мы добились более плавного и быстрого перемещения и масштабирования холста, а также увеличили скорость визуализации перетаскивания блоков с подключенными линками. 

    Надеемся, что статья была интересной, мы будем продолжать улучшать продукт и делиться успехами и лайфхаками с вами!

    Voximplant
    Облачная платформа голосовой и видеотелефонии

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое