Ivan Bogachev

GL_INVALID_VALUE: Offset overflows texture dimensions.

Ошибки такого рода в мире WebGL обычно связаны с тем фактом, что мы пытаемся использовать текстуру, но у нас левые ее размеры, и мы, например, пытаемся получать из нее пиксели за ее границами. Искать проблему нужно вокруг этого факта. На сайте PixiJS можно найти описание основ работы с текстурами, и там сказано, что они кешируются. Если мы делаем Texture.from с тем же источником, то получаем не новую текстуру, а ту, которая уже была. Но в вашем коде где-то по дороге меняются размеры. А сама текстура, сам буфер с пикселями, получается старый, закешированный. Это, вполне вероятно, и вызывает несоответствие. Решением должно быть использование метода destroy() у текстуры, чтобы ее уничтожить с концами при переинициализации. Альтернативно у конструктора Texture.from есть второй параметр skipCache, который по идее даст схожий результат.

В package.json есть раздел overrides как раз для таких модификаций зависимостей зависимостей. В примерах в документации там почему-то акцент сделан только на версии пакетов, но можно и полностью заменить пакет на свой, если указать не версию, а локальный путь к нему.

В CSS и SVG есть какие-то градиенты и фильтры, из которых можно что-то такое плюс-минус собрать. Ну и вариации clip-path или масок, чтобы обрезать. Но. Логика формирования градиентов там своя, и она не всегда хорошо подходит под идею, как оно должно выглядеть. Иногда все мешается очень грязно, или какие-то полосы появляются. Не идеально там все. Много костылей нужно подставлять. Если будет нужна какая-то совсем особая интерполяция - то от количества костылей и подпорок тошно станет. Один раз подогнать можно, но с автоматизацией могут возникнуть сложности. А задача построения диаграмм почти всегда требует автоматизации. Это может быть не совсем очевидно с самого начала, но усугубляется там все очень быстро. Так что может иметь смысл сразу брать canvas и делать свою логику под свои хотелки. Там мы нарисовать можем что угодно, мы уже не зависим от браузера и его представлений о градиентах. Это более сложное решение в своей основе, чем подбор градиентов в SVG, но более перспективное в плане его дальнейшего развития.

У вас примеры с new и без new не эквивалентны. Вы просто посмотрите, что там на самом деле находится в получаемых переменных:

function Foo(arg) {
    this.bar = function() {
        return arg;
    };

    return this.bar();
}

const notfoo = Foo('not foo');
console.log(notfoo); // "not foo", т.е. notfoo - это не новый Foo, это строка текста.
console.log(notfoo.bar); // undefined, что логично, у стандартной строки никакого bar нет.

const foo = new Foo('foo');
console.log(foo); // [object Object], т.е. вот это - настоящий новый Foo.
console.log(foo.bar); // function() { ... }, и метод bar в нем есть.
console.log(foo.bar()); // "foo"

Метод querySelector возвращает первый элемент, который соответствует селектору. В вашем конкретном случае querySelector('.btn') - это всегда первая кнопка. Тут вопрос не в количестве кликов, а в том, что логика действий завязана на первую кнопку.

Могу предположить что что-то на подобии gsap

Если рассматривать эту задачу в целом, без привязки к конкретному сайту, то это задача по созданию мультиков, в больших количествах, на потоке, в рамках сформированной дизайнерской системы. Делать это за счет фронтендеров - такая себе идея. Сложно всех синхронизировать, очень много накладных расходов. Это будет реально дорогая разработка. И разработчики нужны очень прошаренные по части анимаций, чтобы они были со всей командой дизайнеров на одной волне. Таких днем с огнем не найдешь. Более простой и дешевый подход состоит в том, чтобы этим всем занимались моушен-дизайнеры в рамках экосистемы Lottie. А со стороны разработки мы только интегрировали готовые сценки в сайт или приложение. В последние годы обычно все так и делают. Наш стек здесь не имеет значения, равно как и умения разработчиков.

Вероятно вам нужен обычный transition, он будет срабатывать каждый раз, когда значения будут меняться:

.items {
    .single-chart {
        .circular-chart {
            .circle {
                /* animation: progress 1s ease-out forwards; */
                transition: stroke-dasharray 1s ease-out;
            }
        }
    }
}

Prettier использует определенную логику для определения ситуаций, когда такие вещи должны быть разделены. Ее нельзя выключить. Этот инструмент в целом имеет очень мало настроек, он изначально очень строгий и нацелен на то, чтобы навязать свой стиль форматирования везде. В этом его философия. Не нужно спорить, как лучше форматировать. Робот все решит за нас.

Можно игнорировать какие-то конкретные штуки с помощью комментария // prettier-ignore. Но нужно ли?

если я перейду на визуализатор pixi то будет ли существенное повышение производительности?

Matter использует 2D канвас (если мы говорим про их стандартный рендерер). Pixi - WebGL. Ваш вопрос получается не про Pixi, как библиотеку, а про разницу технологий.

Когда-то было такое время, что 2D-канвас рендерился полностью на CPU, и тогда разница между ним и WebGL была в первую очередь обусловлена этим фактом. WebGL - это более низкоуровневый интерфейс с доступом к видеокарте. Много ядер, процессы хорошо распараллеливаются, при наличии прямых рук и понимания основ компьютерной графики все рендерится быстрее. Но в наше время и 2D-канвасы ускоряются видеокартой. Если очень грубо говорить, то сейчас 2D канвас - это тот же GL-канвас, но с более высокоуровневой обвязкой сверху. Чисто для удобства. Можно сказать, что разница в алгоритмах самого рендеринга с годами сводится к нулю, остается лишь разница в обвязке. Изначальная высокоуровневая структура вокруг 2D-канваса с кучей условно ненужного в конкретных случаях функционала не оптимизируются так эффективно, как бы нам хотелось. Она не умеет предсказывать наши намерения. Из-за этого переход от 2D к WebGL может дать прирост производительности. Но не столько за счет самого рендеринга, сколько за счет более умного переиспользования ресурсов и избавления от всех ненужных в конкретных случаях операций. Так что в целом идея взять двумерный рендерер на WebGL и делать в нем только то, что требуется, и ничего лишнего - все еще хорошая. Плюс у него будет сразу задел на использование своих кастомных шейдеров, что открывает целый мир визуальных эффектов, неподвластных 2D-канвасу.

Но не стоит ждать чуда - уменьшение времени обработки одного среднестатистического игрового кадра в 2-3 раза можно будет считать хорошим результатом. Тесты, в которых люди меряют разницу в десятки раз, обычно завязаны на какие-то узкие случаи с переиспользованием ресурсов. Далеко не факт, что это будет ваш случай. Так что если у вас там что-то конкретно тормозит - может быть будет больше пользы от оптимизации узких мест в текущей логике, чем от машинального переписывания всего на других инструментах.

В изначальных исходниках там TypeScript. Вы смотрите уже скомпилированный код. В исходниках местами все обернуто в разные условия, завязанные на__DEV__:

export function setExtraStackFrame(stack: null | string): void {
  if (__DEV__) {
    currentExtraStackFrame = stack;
  }
}

Когда происходила сборка кода, который вы смотрите, вероятно __DEV__ был true, условие было опущено, т.к. оно всегда выполняется, а скобки остались как артефакт. Скорее всего транспилятор TS не проверяет весь контекст, и чтобы ничего не сломать случайно, оставляет скобки на своих местах.

Никакой Three.js тут не нужен. Ну то есть, конечно, никто не мешает сделать все это на WebGL и прикрутить здоровенный фреймворк сверху, но все же это будет слегка избыточным решением в большинстве случаев. Такое можно аргументировать только если весь сайт изначально так и делается на WebGL и это просто "один из" эффектов, которые туда нужно интегрировать.

В 99% остальных случаев подобные штуки делаются одной svg-картинкой, одним path, который рисуется в зависимости от положения мышки и размеров контейнера. Немного школьной геометрии, ограничение диапазона возможных смещений всего этого - и дальше можно до посинения играть с алгоритмом расчета смещения, до тех пор, пока реакция на мышку не начнет нравится. Там уже нет универсального рецепта, все от дизайна зависит. Можно линейно привязать к положению мыши. Это обычно выглядит скучно. Можно использовать какую-то функцию от расстояния до центра, чтобы сделать движения менее равномерными. В каких-то случаях делают полноценный эффект инерции, как верно подмечено в соседнем ответе. Там получаются более естественные движения (обычно все это является развитием гравитационных моделей). Есть совсем замороченный подход, когда используется моделирование системы пружин (для общего развития можно загуглить силовые алгоритмы визуализации графов). Там можно получить целый ряд занятных эффектов, которые часто оказываются в тему как раз в таких фонах, где какие-то штуки связаны между собой прямыми линиями. Ну и можно просто вдохновиться какими-то физическими явлениями и сделать что-то "по мотивам".

В codepen я нашел интересный проект...

Это WebGL Fluid Simulation. И оригинальная ее версия на телефонах работает хорошо. Вы нашли какую-то из вариаций на тему этой штуки. Думаю для вас будет проще взять оригинал, а не отлаживать тот пример, который вы нашли.

через css хочу скрыть его, когда пуст

В такой формулировке можно обойтись без дополнительных классов:

.wishlist_products_counter_number:empty {
    display: none;
}

На этом сайте используется какая-то из версий WebGL Fluid Simulation.

var video = document.querySelector('video');

У вас в body нет ни одного тега video, соответственно с помощью querySelector не находится ничего, переменная video равна null, и дальше все ломается. Добавьте тег video и все заработает.