Pixi.js: https://pixijs.github.io/bunny-mark/ lent

Comment se compare-t-il aux versions précédentes?

Oui, c'est très optimiste, je n'ai vu qu'une seule fois un ordinateur de bureau qui gérait 100 000 lapins multitexturés à 75 images par seconde. J'en ai 18 aussi :)

Essayez de lancer une version sans multi-texturation, il y avait un bouton.

PIXI est optimisé pour un jeu « moyen », mais il a de nombreux paramètres, et vous pouvez même écrire votre propre moteur de rendu super-optimisé au-dessus de l'architecture pixi ! Nous avons 10000 vaches animées (~16 quads chacune), à ​​30FPS stables sur de vieilles cartes vidéo et Intel HD. Scène extrême, très faible utilisation du processeur : https://www.youtube.com/watch?v=adixpp9CK_A . Plus les objets changent de coordonnées, plus le processeur est utilisé, et il peut gérer les cas où tout se déplace à chaque image à un FPS suffisant. J'espère sortir cette fourchette de pixi dans un mois ou deux :)

Cette fourchette sera-t-elle fusionnée dans le maître pour rendre le pixi génial à nouveau ?

Ivan, ce que vous obtenez en utilisant Pixi est très impressionnant. Hâte de voir cette fourchette et d'en tirer des leçons. :)

@jeebus3000 Non, ce sera un fork de production, cela nécessitera une connaissance approfondie de pixi et webgl.

Le nombre de paramètres sera élevé :

1. Spécifiez comment votre format d'animation json se convertit en format binaire adapté au GPU. Pré-défini : juste une feuille de sprite, une animation flash, une colonne vertébrale. Tous avec des paramètres différents (flotteurs par instance, flotteurs par quad)
2. pixi-display++ : tandis que pixi a un conteneur, il y aura aussi une scène, un calque et une caméra. Chaque DisplayObject a une vue qui appartient à une couche, et pour les cas extrêmes (gameofbombs.com), il y aura un certain nombre de vues par objet.
3. updateTransform() n'est pas appelé à chaque frame, et il y a plus de mises à jour paresseuses que dans vanilla pixi. Nous ne voulons pas que les éléments 10k soient appelés dans JS lorsqu'ils ne se déplacent pas sur la carte.
4. atlas en temps réel et textures compressées. Lorsque vous développez un jeu, vous devez regarder ce qui se passe dans la mémoire vidéo et comment les atlas sont formés. Les atlas sont créés avec des paramètres spéciaux dans les packers de texture avant d'être compressés dans le format résultant.

@bigtimebuddy

Comment se compare-t-il aux versions précédentes?

Lorsque je clique sur "v3.0.8", j'obtiens ceci :

Idem pour 3.0.9, 3.0.10.

Signalé au #4023 .

Avec 3.0.11 j'obtiens 6fps.

Avec 4.0.0 et 4.0.1 j'obtiens 23-24fps.

A partir de là, il y a une régression constante :

Avec 4.1.0 et 4.1.1, j'obtiens 20-22fps.

Avec 4.2.1 j'obtiens 19-20fps.

Avec 4.4.4 et 4.5.1 j'obtiens 16-18fps.

J'espère que Pixi redeviendra plus rapide.

cc @GoodBoyDigital

@ivanpopelyshev C'est impressionnant ! Mais j'ai besoin que PixiJS stock soit extrêmement rapide (et mes cas d'utilisation ressemblent souvent à des bunnymarks).

Peut-être qu'il pourrait y avoir un test (qui est toujours exécuté) qui vérifie si le dernier code Pixi est aussi rapide (ou plus rapide) que le plus rapide des versions précédentes.

De plus, peut-être que le bunnymark devrait être modifié pour utiliser de petits lapins à texture unique si cela aide à perf. Il pourrait y avoir une option pour les lapins plus gros / multi-texturés (et même animés en eux-mêmes) (avec un nombre par défaut beaucoup plus faible). (Ces options nécessiteraient des boutons supplémentaires qui n'existent pas actuellement.)

Si, après tout cela, le nombre par défaut de 100000 est encore trop optimiste, il doit être remplacé par quelque chose de beaucoup plus bas, de sorte que lorsque quelqu'un est envoyé au bunnymark PixiJS (et qu'il est exécuté avec les valeurs par défaut), PixiJS n'aura pas l'air mauvais. Au lieu du faible taux de rafraîchissement actuel, les gens devraient voir un 60fps agréable et fluide.

@tobireif vous n'avez qu'un seul paramètre ici : le nombre de textures dans spriterenderer. Faites un grand atlas 4k x 4k ou 8k x 8k et ce sera bien mieux que la multitexture.

Vous devez tester les paramètres Webgl de vos utilisateurs, les optimisations ne sont pas possibles sans ces informations. À titre d'exemple, nous savons que 99% ont un plugin de textures 4k et de textures flottantes, et nous l'utilisons beaucoup, contrairement au moteur de rendu vanilla pixi.

Dans mon cas, pixi est comme un passe-partout pour de meilleurs rendus adaptés à des tâches spécifiques.

@ivanpopelyshev

nombre de textures dans spriterenderer. Faites un grand atlas 4k x 4k ou 8k x 8k et ce sera bien mieux que la multitexture.

Si cela aide à améliorer les performances, cela devrait être implémenté dans le bunnymark PixiJS, n'est-ce pas ?

De la version 4.0.1 à 4.5.1, PixiJS est devenu plus lent - le framerate de bunnymark est passé de 23-24fps à 16-18fps . Ce problème doit être résolu, puis les régressions de performances doivent être évitées à l'avenir (par exemple, en utilisant un test CI).

Dans mon cas, pixi est comme un passe-partout pour de meilleurs rendus adaptés à des tâches spécifiques.

J'ai besoin que "vanilla PixiJS" soit extrêmement performant, et je soupçonne que d'autres utilisateurs de Pixi JS le font aussi.

Oui, nous avons besoin d'un champ de texte supplémentaire dans la configuration, comme "nombre de textures : ». Quant à 4.0.1-4.5.1 , je pense que nous devons d'abord comprendre si son CPU ou son GPU nous avons désoptimisé.

@tobireif , c'est un bon point ! Nous devrions probablement le démarrer sur quelque chose de bien plus bas - peut-être 1000 ? Est-ce un ajustement facile @bigtimebuddy ?

En ce qui concerne les performances, nous échangeons essentiellement plus de flexibilité contre de la puissance. Il y a aussi un peu de biais sur le contenu statique dans la version actuelle de pixi (car la plupart des choses ont tendance à ne pas bouger !)

Bunnymark s'exécute beaucoup plus rapidement si vous utilisez un conteneur de particules :)

Mais c'est un bon cri, je travaille actuellement sur la v5, je vais voir si nous pouvons récupérer ces fps !

@ivanpopelyshev Je suis revenu à l'ancienne méthode 4.0.0 de liaison de texture dans la v5 (moins de magie - je me promène si cela peut aider!)

@GoodBoyDigital qui vous aidera. la liaison de texture intelligente fonctionnait UNIQUEMENT dans une chose à texture unique, toute utilisation multitexture était pénible.

Salut les gars, quelle version avons-nous convertie en es6 ? Je connais un peu ce hit perf !

@GoodBoyDigital

La marque de lapin est une chose. Il est important qu'il soit rapide, car il est censé montrer que Pixi est rapide. Et parce que c'est un exemple de perf (dont les sources pourraient étudier et paraphraser), il devrait présenter toutes les optimisations possibles et sensées côté utilisateur de lib. Et le nombre de lapins devrait toujours être un nombre impressionnant, par exemple 40000 ou 50000 (par exemple le nombre le plus élevé qui apporte 60fps avec les améliorations mentionnées dans ce ticket et avec Pixi version 5 sur par exemple ma machine/Ivan).

Mais quel que soit le code bunnymark, Pixi lui-même doit être extrêmement rapide, comme nous en sommes tous d'accord.

J'espère que vous pourrez tous atteindre et maintenir d'excellentes performances !

Il y a aussi un peu de biais sur le contenu statique dans la version actuelle de pixi (car la plupart des choses ont tendance à ne pas bouger !)

Chaque fois que j'utilise Pixi, la plupart des choses bougent

Bunnymark s'exécute beaucoup plus rapidement si vous utilisez un conteneur de particules :)

Ainsi, le code bunnymark devrait utiliser un conteneur de particules, n'est-ce pas ?

Je travaille actuellement sur la v5, je vais voir si on peut récupérer ces fps !

Super! ??

Je ne suis pas d'accord avec le but supposé de bunny-mark ici. Le but n'est pas nécessairement de montrer quelque chose qui tourne à 60fps. Nous l'utilisons comme moyen de comparer les performances relatives des versions/dev et comme test de fumée. Jusqu'à ce que nous ayons de bons moyens d'analyse comparative, c'est notre meilleur outil en ce moment pour évaluer les impacts sur les performances. 100000 lapin était intentionnel pour vraiment pousser le moteur de rendu à l'endroit où il aurait du mal. Si nous voulons montrer à quel point Pixi est rapide, ce n'est pas la bonne chose pour le travail. J'aurais écrit quelque chose en utilisant ParticleCointainer, comme ~Ivan~ Mat l'a suggéré.

Nous savons qu'il y a eu une légère baisse des performances dans la v4.1+ et cela est dû en grande partie au fait que nous avons réécrit la base de code dans ES6 pour la rendre plus maintenable. L'équipe de base a estimé que le petit coup de performance valait le compromis à long terme.

J'ai quelques suggestions sur la façon dont nous pourrions résoudre ce problème :

• [ ] créer une publicité de performance plus sexy et conviviale pour Pixi, de préférence quelque chose dans des exemples. Peut avoir des commandes à grain fin pour basculer les fonctionnalités. Conservez bunny-mark comme outil de test interne uniquement.
• [ ] continuer à améliorer le wiki pour obtenir des conseils sur les performances, en fournissant potentiellement des démos
• [ ] mettre en œuvre des tests d'analyse comparative pour Pixi, quelque chose de cohérent à mesurer
• [ ] vérifier les baisses de performances sur les versions les plus récentes comme indiqué ci-dessus

Ce problème doit être résolu, puis les régressions de performances doivent être évitées à l'avenir

Bien sûr, nous devons améliorer l'analyse comparative des performances, et bien sûr, ce serait formidable de l'intégrer dans CI, et bien sûr, Pixi doit être aussi rapide que possible. Mais nous avons également besoin de personnes prêtes à donner de leur temps pour aider à résoudre ces problèmes très complexes. S'il y a des gens là-bas avec une expérience particulière en matière de tests de performances sur divers navigateurs/matériels, ils seraient les bienvenus ici !

Et toi, @tobireif ? Avez-vous une expertise dans ces domaines? Beaucoup d'opportunités de s'améliorer. Bienvenue PRs ou efforts ici pour profiler, pour créer de meilleurs tests, pour trouver des solutions pour faire CI (Travis) avec webgl, pour faire des recherches binaires sur l'historique des commits à la recherche de contributions négatives aux performances.

De plus, je voudrais préciser que bunnymark existait en plusieurs versions, mais il y a quelques mois, j'ai demandé à @bigtimebuddy de m'aider, je suis

Je pense que le nombre de textures est la seule tâche critique pour les benchmarks.

@bigtimebuddy

Merci d'avoir posé la question. J'ai de l'expérience dans l'optimisation des performances, mais je ne pourrai malheureusement pas trouver le temps de travailler directement sur Pixi dans un avenir prévisible. J'espère que mes contributions sous la forme de ce (et d'autres) rapports de problème seront toujours appréciées (elles prennent aussi du temps ...)

Je comprends maintenant que "pixijs.github.io/bunny-mark" est destiné aux tests de performances internes au dev.

Donc, si je devais montrer à quelqu'un la grande perf de PixiJS (par exemple en recommandant Pixi pour un projet spécifique), je lierais ceci http://www.goodboydigital.com/pixijs/bunnymark/ ?
(au lieu de https://pixijs.github.io/bunny-mark/ )
(Bien qu'il puisse y avoir des démos de performances supplémentaires à l'avenir, j'aime le bunnymark, et il fait le travail de manière impressionnante.)

(Je pense que présenter les performances aux utilisateurs potentiels de la bibliothèque était l'objectif initial des premiers/précédents bunnymarks, il a été publié dans les articles du blog GoodBoy, etc., ce n'était pas seulement interne au développement.)

BTW, http://www.goodboydigital.com/pixijs/bunnymark/ utilise ParticleContainer, mais une ancienne version de Pixi.

Encore une fois, à vous tous :

Merci pour PixiJS !

@GoodBoyDigital

Je travaille actuellement sur la v5, je vais voir si on peut récupérer ces fps !

Super! J'ai hâte

Peut-être qu'il pourrait y avoir un bunnymark v5 (un pour présenter les performances de Pixi, comme le bunnymark v3 existant http://www.goodboydigital.com/pixijs/bunnymark_v3/ ).

Salut! Fermeture de ce problème pour l'instant en raison de son inactivité. N'hésitez pas à nous donner un coup de coude si vous souhaitez que ce problème soit réouvert. Merci

Pas de problème

Mais ce serait toujours génial s'il y avait toujours un bunnymark pour la dernière version respective, dans le seul but de présenter les performances d'animation impressionnantes de PixiJS (quelque chose de différent du smoke-test-bunnymark utilisé par PixiJS-lib-developers) . Lier une démo d'animation impressionnante telle que bunnymark est utile lors de la promotion de PixiJS, par exemple dans les tweets. (Le dernier bunnymark respectif ne devrait pas être plus lent que les précédents / devrait prendre en charge au moins le même nombre de lapins à 60 images par seconde que les bunnymarks précédents. Il utiliserait probablement ParticleCointainer.)

Si cela est dans le cadre du projet PixiJS, veuillez rouvrir (ou nous pourrions coller ce qui précède dans un nouveau ticket).

Il y a également plusieurs lignes importantes dans ce ticket ici, par exemple "Implémenter des tests d'analyse comparative pour Pixi, quelque chose de cohérent à mesurer" par Matt Karl.

Connexe : https://github.com/pixijs/pixi.js/issues/4026 .

Ce fil a été automatiquement verrouillé car il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues liés.