Pixi.js: https://pixijs.github.io/bunny-mark/ медленно

Как это по сравнению с предыдущими версиями?

Да, это очень оптимистично, я только однажды видел рабочий стол, который обрабатывал 100k мультитекстурных кроликов со скоростью 75FPS. У меня тоже 18 :)

Попробуйте запустить версию без мультитекстурирования, была кнопка.

PIXI оптимизирован для "средней" игры, но у него много параметров, и вы даже можете написать свой собственный супероптимизированный рендерер поверх архитектуры pixi! У нас есть 10000 анимированных коров (~ 16 квадратов каждая), стабильная 30FPS на старых видеокартах и ​​Intel HD. Экстремальный этап, очень низкая загрузка ЦП: https://www.youtube.com/watch?v=adixpp9CK_A. Чем больше объектов меняют свои координаты, тем больше используется ЦП, и он может обрабатывать случаи, когда все движется каждый кадр с достаточной частотой кадров. Я надеюсь выпустить вилку pixi через месяц или два :)

Будет ли эта вилка объединена с мастером, чтобы Pixi снова стал отличным?

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

@ jeebus3000 Нет, это будет производственная вилка, для этого потребуются глубокие знания pixi и webgl.

Количество настроек будет большим:

1. Укажите, как ваш формат анимации json преобразуется в двоичный формат, подходящий для графического процессора. Предустановлено: просто таблица спрайтов, флэш-анимация, корешок. Все с разными настройками (число с плавающей запятой на экземпляр, число с плавающей точкой на квад)
2. pixi-display ++: в то время как у pixi есть Контейнер, также будут Сцена, Слой и Камера. Каждый DisplayObject имеет представление, которое принадлежит какому-либо слою, а в крайних случаях (gameofbombs.com) будет несколько представлений для каждого объекта.
3. updateTransform () вызывается не каждый кадр, и ленивых обновлений больше, чем в vanilla pixi. Мы не хотим, чтобы в JS вызывалось 10 тыс. Элементов, когда они не перемещаются по карте.
4. атласы в реальном времени и сжатые текстуры. Когда вы разрабатываете игру, вы должны смотреть, что происходит в видеопамяти и как формируются атласы. Атласы создаются со специальными настройками в упаковщиках текстур перед сжатием в итоговый формат.

@bigtimebuddy

Как это по сравнению с предыдущими версиями?

Когда я нажимаю "v3.0.8", я получаю следующее:

То же самое для 3.0.9, 3.0.10.

Об этом сообщается на # 4023.

С 3.0.11 я получаю 6 кадров в секунду.

С 4.0.0 и 4.0.1 я получаю 23-24 кадра в секунду.

С этого момента происходит постоянный регресс:

С 4.1.0 и 4.1.1 я получаю 20-22 кадра в секунду.

С 4.2.1 я получаю 19-20 кадров в секунду.

С 4.4.4 и 4.5.1 я получаю 16-18 кадров в секунду.

Надеюсь, Pixi снова станет быстрее.

cc @GoodBoyDigital

@ivanpopelyshev Впечатляет! Но мне нужен стандартный PixiJS, чтобы он был чрезвычайно быстрым (а мои варианты использования часто выглядят как следы кролика).

Возможно, существует тест (который выполняется всегда), который проверяет, является ли последний код Pixi таким же быстрым (или быстрее), как самый быстрый из предыдущих версий.

Кроме того, возможно, следует изменить отметку кролика, чтобы использовать небольших кроликов с одной текстурой, если это помогает производительности. Может быть вариант для больших кроликов с множеством текстур (и даже анимированных в себе) (с гораздо меньшим количеством по умолчанию). (Для этих параметров потребуются дополнительные кнопки, которых в настоящее время нет.)

Если после всего этого счетчик по умолчанию 100000 все еще слишком оптимистичен, его следует изменить на что-то значительно меньшее, чтобы, когда кто-то отправляется на PixiJS bunnymark (и он запускается со значениями по умолчанию), это не заставит PixiJS выглядеть плохо. Вместо нынешней низкой частоты кадров люди должны видеть приятные и плавные 60 кадров в секунду.

@tobire, если у вас там только одна настройка: количество текстур в spriterenderer. Сделайте один большой атлас 4k x 4k или 8k x 8k, и он будет намного лучше, чем мультитекстура.

Вы должны проверить, какие настройки webgl есть у ваших пользователей, без этой информации оптимизация невозможна. Например, мы знаем, что 99% имеют плагин 4k текстур и плавающих текстур, и мы его часто используем, в то время как vanilla pixi renderer нет.

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

@ivanpopelyshev

количество текстур в spriterenderer. Сделайте один большой атлас 4k x 4k или 8k x 8k, и он будет намного лучше, чем мультитекстура.

Если это помогает производительности, то это должно быть реализовано в PixiJS bunnymark, верно?

С версии 4.0.1 до 4.5.1 PixiJS стал медленнее - частота кадров Bunnymark упала с 23-24 кадров в секунду до 16-18 кадров в секунду. Эту проблему необходимо исправить, а затем предотвратить регрессию производительности в будущем (например, с помощью теста CI).

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

Мне нужен «vanilla PixiJS», чтобы быть чрезвычайно производительным, и я подозреваю, что другие пользователи Pixi JS тоже.

Да, нам нужно еще одно текстовое поле в настройке, например «количество текстур:». Что касается 4.0.1-4.5.1, я думаю, сначала мы должны понять, деоптимизировали ли мы его CPU или GPU.

@tobireif , это хороший момент! Вероятно, нам стоит начать с чего-то более низкого - может быть, с 1000? Это простая настройка @bigtimebuddy?

Что касается производительности, мы в основном жертвуем большей гибкостью в пользу мощности. В текущей версии pixi тоже есть некоторая предвзятость по поводу статического контента (так как большинство вещей, как правило, не перемещаются!)

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

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

@ivanpopelyshev Я вернулся к старому способу привязки текстур 4.0.0 в v5 (меньше магии - я блуждаю, если это поможет!)

@GoodBoyDigital , это поможет. умная привязка текстур работала ТОЛЬКО в однотекстурных вещах, всякое использование мультитекстур было болезненным.

Привет, ребята, какую версию мы преобразовали в es6? Я знаю, что производительность немного выше!

@GoodBoyDigital

Зайчик - это одно. Важно, чтобы он был быстрым, потому что он должен показать, что Pixi быстр. И поскольку это пример производительности (исходники которого могут изучить и перефразировать), он должен демонстрировать все возможные и разумные оптимизации на стороне пользователя lib. И количество кроликов по-прежнему должно быть впечатляющим, например 40000 или 50000 (например, максимальное количество, которое дает 60 кадров в секунду с улучшениями, упомянутыми в этом билете, и с Pixi версии 5, например, на моей машине / машине Ивана).

Но независимо от кода Bunnymark, Pixi, как мы все согласны, должен быть чрезвычайно быстрым.

Я надеюсь, что вы все сможете достичь и поддерживать отличную производительность!

В текущей версии pixi тоже есть некоторая предвзятость по поводу статического контента (так как большинство вещей, как правило, не перемещаются!)

Когда я использую Pixi, большинство вещей движется 😀

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

Таким образом, код bunnymark должен использовать контейнер для частиц, верно?

В настоящее время я работаю над v5, посмотрю, сможем ли мы вернуть этот fps!

Большой! 👍

Я не согласен с предполагаемым назначением отметки кролика здесь. Цель состоит в том, чтобы не обязательно показывать что-то, работающее со скоростью 60 кадров в секунду. Мы используем это как способ сравнения относительной производительности релизов / dev и в качестве дымового теста. Пока у нас нет хороших способов тестирования, это наш лучший инструмент для оценки влияния на производительность. 100000 bunny были намерены действительно подтолкнуть рендерер к тому месту, где он будет бороться. Если мы хотим показать, насколько быстр Pixi, это не то, что нужно для работы. Я бы написал что-нибудь с помощью ParticleCointainer, как предложил Иван Мат.

Мы знаем, что в версии 4.1+ было небольшое снижение производительности, во многом из-за того, что мы переписали кодовую базу в ES6, чтобы сделать ее более удобной в обслуживании. Основная команда чувствовала, что небольшое снижение производительности стоило компромисса в долгосрочной перспективе.

У меня есть несколько предложений, как мы можем решить эту проблему:

• [] создайте более привлекательную и удобную рекламу для Pixi, желательно что-нибудь в виде примеров. Могут иметь мелкие элементы управления для переключения функций. Сохраняйте bunny-mark только в качестве инструмента для внутреннего тестирования.
• [] продолжайте улучшать вики для получения советов по производительности, потенциально предоставляя демонстрации
• [] внедрить сравнительные тесты для Pixi, что-то, что можно измерить
• [] проверьте падение производительности на самых последних версиях, как указано выше

Эту проблему необходимо исправить, а затем предотвратить регрессию производительности в будущем.

Конечно, нам нужно улучшить бенчмаркинг производительности, и, конечно, было бы здорово интегрироваться в CI, и, конечно, Pixi должен быть как можно быстрее. Но нам также нужны люди, которые готовы потратить время на решение этих очень сложных проблем. Если есть люди с определенным опытом, выполняющие тесты производительности в различных браузерах / оборудовании, мы будем рады внести здесь свой вклад!

А ты, @tobireif? У вас есть опыт в этих областях? Множество возможностей для улучшения. Приветствуем PR или усилия по профилированию, созданию лучших тестов, поиску решений для выполнения CI (Travis) с помощью webgl, выполнения бинарного поиска в истории коммитов в поисках отрицательного влияния на производительность.

Кроме того, я хотел бы заявить, что bunnymark существовал в нескольких версиях, но несколько месяцев назад я попросил @bigtimebuddy помочь с этим, я ужасно

Считаю, что количество текстур - единственная критическая задача для тестов.

@bigtimebuddy

Спасибо за вопрос. У меня есть опыт оптимизации производительности, но, к сожалению, я не смогу найти время для непосредственной работы над Pixi в обозримом будущем. Я надеюсь, что мой вклад в виде этого (и других) отчетов о проблемах по-прежнему будет оценен (они также требуют времени ...)

Теперь я понимаю, что "pixijs.github.io/bunny-mark" предназначен для внутреннего тестирования производительности разработчика.

Так что, если бы я показал кому-нибудь отличную производительность PixiJS (например, рекомендуя Pixi для конкретного проекта), я бы связал это http://www.goodboydigital.com/pixijs/bunnymark/ ?
(вместо https://pixijs.github.io/bunny-mark/)
(Хотя в будущем могут появиться дополнительные демонстрации производительности, мне нравится Bunnymark, и он отлично справляется со своей задачей.)

(Я думаю, что демонстрация производительности потенциальным пользователям библиотеки была первоначальной целью первых / более ранних bunnymarks, она была размещена в сообщениях в блогах GoodBoy и т. Д., Это не было просто внутренней разработкой.)

Кстати, http://www.goodboydigital.com/pixijs/bunnymark/ использует ParticleContainer, но более старую версию Pixi.

Опять же, всем вам:

Спасибо за PixiJS!

@GoodBoyDigital

В настоящее время я работаю над v5, посмотрю, сможем ли мы вернуть этот fps!

Звучит здорово! С нетерпением жду этого 😀

Возможно, там может быть bunnymark v5 (один для демонстрации производительности Pixi, как существующий bunnymark v3 http://www.goodboydigital.com/pixijs/bunnymark_v3/).

Всем привет! На данный момент закрываем этот вопрос из-за его бездействия. Не стесняйтесь дать нам понять, если вы хотите, чтобы эта проблема была повторно открыта. Спасибо 👍

Нет проблем 😀

Но все равно было бы здорово, если бы для соответствующего последнего выпуска всегда был значок кролика, с единственной целью продемонстрировать впечатляющую производительность анимации PixiJS (что-то отличное от Smoke-test-bunnymark, используемого разработчиками PixiJS-lib). . Связывание впечатляющей демонстрации анимации, такой как bunnymark, полезно при продвижении PixiJS, например, в твитах. (Соответствующий последний bunnymark не должен быть медленнее, чем предыдущие / должен поддерживать как минимум такое же количество кроликов со скоростью 60 кадров в секунду, что и предыдущие bunnymark. Вероятно, он будет использовать ParticleCointainer.)

Если это относится к проекту PixiJS, пожалуйста, откройте его повторно (или мы могли бы вставить вышеуказанное в новый тикет).

Кроме того, в этом билете есть несколько важных строк, например: «Проведите сравнительные тесты для Pixi, что-то, что можно измерить» Мэтта Карла.

По теме: https://github.com/pixijs/pixi.js/issues/4026 .

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