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

¿Cómo se compara con versiones anteriores?

Sí, es muy optimista, solo una vez vi una computadora de escritorio que manejaba 100k conejitos de múltiples texturas a 75FPS. Yo también tengo 18 :)

Intente ejecutar una versión sin texturas múltiples, había un botón.

PIXI está optimizado para juegos "promedio", pero tiene muchos parámetros, ¡e incluso puedes escribir tu propio renderizador súper optimizado sobre la arquitectura pixi! Tenemos 10000 vacas animadas (~ 16 quads cada una), a 30 FPS estables en tarjetas de video antiguas e Intel HD. Etapa extrema, uso de CPU muy bajo: https://www.youtube.com/watch?v=adixpp9CK_A. Cuantos más objetos cambien sus coordenadas, más CPU se utiliza y puede manejar casos en los que todo se mueve en cada fotograma a suficientes FPS. Espero lanzar esa bifurcación de pixi en un mes o dos :)

¿Esta bifurcación se fusionará con el maestro para hacer que pixi vuelva a ser genial?

Ivan lo que logras usando Pixi es muy impresionante. Esperamos ver esta bifurcación y aprender de ella. :)

@ jeebus3000 No, será una bifurcación de producción, requerirá un conocimiento profundo de pixi y webgl.

La cantidad de configuraciones será alta:

1. Especifique cómo se convierte su formato de animación json a formato binario adecuado para GPU. Predefinido: solo una hoja de sprites, animación flash, columna vertebral. Todos con diferentes configuraciones (flotadores por instancia, flotadores por quad)
2. pixi-display ++: mientras pixi tiene Container, también habrá Stage, Layer y Camera. Cada DisplayObject tiene una Vista que pertenece a alguna capa, y para casos extremos (gameofbombs.com) habrá una cantidad de vistas por objeto.
3. updateTransform () no se llama en todos los fotogramas, y hay más actualizaciones perezosas que en vanilla pixi. No queremos que se invoquen 10k elementos en JS cuando no se mueven por el mapa.
4. atlas en tiempo real y texturas comprimidas. Cuando desarrollas un juego, debes observar lo que sucede en la videomemoria y cómo se forman los atlas. Los atlas se hacen con ajustes especiales en empaquetadores de texturas antes de comprimirlos en el formato resultante.

@bigtimebuddy

¿Cómo se compara con versiones anteriores?

Cuando hago clic en "v3.0.8", obtengo esto:

Lo mismo ocurre con 3.0.9, 3.0.10.

Reportado en # 4023.

Con 3.0.11 obtengo 6 fps.

Con 4.0.0 y 4.0.1 obtengo 23-24 fps.

A partir de aquí hay una regresión constante:

Con 4.1.0 y 4.1.1 obtengo 20-22 fps.

Con 4.2.1 obtengo 19-20 fps.

Con 4.4.4 y 4.5.1 obtengo 16-18 fps.

Espero que Pixi vuelva a ser más rápido.

cc @GoodBoyDigital

@ivanpopelyshev ¡ Eso es impresionante! Pero necesito que el stock de PixiJS sea extremadamente rápido (y mis casos de uso a menudo parecen marcas de conejo).

Quizás podría haber una prueba (que siempre se ejecuta) que verifique si el último código de Pixi es tan rápido (o más rápido) como la más rápida de las versiones anteriores.

Además, quizás la marca de conejito debería cambiarse para usar conejitos pequeños de una sola textura si eso ayuda al rendimiento. Podría haber una opción para conejos más grandes / con múltiples texturas (e incluso animados en sí mismos) (con un recuento predeterminado mucho más bajo). (Estas opciones requerirían botones adicionales que no existen actualmente).

Si después de todo esto, el recuento predeterminado de 100000 sigue siendo demasiado optimista, debería cambiarse a algo significativamente más bajo, de modo que cuando alguien sea enviado al bunnymark de PixiJS (y se ejecute con los valores predeterminados), PixiJS no se verá mal. En lugar de la velocidad de fotogramas baja actual, la gente debería ver unos 60 fps agradables y suaves.

@tobire si solo tiene una configuración allí: conteo de texturas en spriterenderer. Haga un gran atlas de 4k x 4k o 8k x 8k y será mucho mejor que la multitextura.

Tienes que probar qué configuraciones webgl tienen tus usuarios, las optimizaciones no son posibles sin esa información. Como ejemplo, sabemos que el 99% tiene texturas 4k y plugin de texturas flotantes, y lo usamos mucho, mientras que el renderizador vanilla pixi no lo tiene.

En mi caso, pixi es como un modelo estándar para mejores renderizadores adecuados para tareas específicas.

@ivanpopelyshev

recuento de texturas en spriterenderer. Haga un gran atlas de 4k x 4k o 8k x 8k y será mucho mejor que la multitextura.

Si eso ayuda al rendimiento de lo que debería implementarse en el bunnymark de PixiJS, ¿verdad?

De la versión 4.0.1 a la 4.5.1, PixiJS se volvió más lento: la velocidad de fotogramas de bunnymark pasó de 23-24 fps a 16-18 fps. Ese problema debe solucionarse, y luego las regresiones de rendimiento deben evitarse para el futuro (por ejemplo, utilizando una prueba de CI).

En mi caso, pixi es como un modelo estándar para mejores renderizadores adecuados para tareas específicas.

Necesito que "vanilla PixiJS" sea extremadamente eficiente, y sospecho que otros usuarios de Pixi JS también lo hacen.

Sí, necesitamos un campo de texto más en la configuración, como "recuento de texturas:". En cuanto a 4.0.1-4.5.1, creo que primero tenemos que entender si hemos desoptimizado su CPU o GPU.

@tobireif , ¡ese es un buen punto! Probablemente deberíamos comenzar con algo mucho más bajo, ¿tal vez 1000? ¿Es un ajuste fácil @bigtimebuddy?

Con respecto al rendimiento, básicamente estamos intercambiando más flexibilidad por potencia. También hay un poco de sesgo en el contenido estático en la versión actual de pixi (¡ya que la mayoría de las cosas tienden a no moverse!)

Bunnymark corre mucho más rápido si usa un contenedor de partículas :)

Pero es un buen grito, actualmente estoy trabajando en la v5, ¡veré si podemos recuperar esos fps!

@ivanpopelyshev Volví a la antigua forma 4.0.0 de unión de texturas en v5 (menos magia, ¡divago si eso ayudará!)

@GoodBoyDigital eso ayudará. La encuadernación de textura inteligente funcionaba ÚNICAMENTE en una sola textura, todo el uso de múltiples texturas era doloroso.

Hola chicos, ¿qué versión convertimos a es6? ¡Conozco ese golpe un poquito!

@BuenoDigital

La marca de conejo es una cosa. Es importante que sea rápido, porque se supone que muestra que Pixi es rápido. Y debido a que es un ejemplo de rendimiento (cuya fuente la gente podría estudiar y parafrasear), debería exhibir todas las optimizaciones posibles y razonables del lado del usuario de la biblioteca. Y el recuento de conejos debería ser un número impresionante, por ejemplo, 40000 o 50000 (por ejemplo, el recuento más alto que ofrece 60 fps con las mejoras mencionadas en este ticket y con la versión 5 de Pixi en, por ejemplo, mi máquina / Ivan).

Pero independientemente del código Bunnymark, Pixi debe ser extremadamente rápido, como todos estamos de acuerdo.

¡Espero que todos puedan lograr y mantener un gran rendimiento!

También hay un poco de sesgo en el contenido estático en la versión actual de pixi (¡ya que la mayoría de las cosas tienden a no moverse!)

Siempre que uso Pixi, la mayoría de las cosas se mueven 😀

Bunnymark corre mucho más rápido si usa un contenedor de partículas :)

Por lo tanto, el código bunnymark debería usar un contenedor de partículas, ¿verdad?

Actualmente estoy trabajando en la v5, ¡veré si podemos recuperar esos fps!

¡Excelente! 👍

No estoy de acuerdo con cuál es el propósito supuesto de bunny-mark aquí. El objetivo es no mostrar necesariamente algo que se ejecute a 60 fps. Usamos esto como una forma de comparar el rendimiento relativo de las versiones / dev y como prueba de humo. Hasta que tengamos buenas formas de realizar evaluaciones comparativas, esta es nuestra mejor herramienta en este momento para medir los impactos en el rendimiento. 100000 bunny fue intencional para realmente empujar al renderizador a un lugar donde estaría luchando. Si queremos presumir de lo rápido que es Pixi, esto no es lo correcto para el trabajo. Habría escrito algo usando ParticleCointainer, como sugirió ~ Ivan ~ Mat.

Sabemos que hubo un ligero impacto en el rendimiento en v4.1 + y gran parte de esto se debió a que reescribimos el código base en ES6 para hacerlo más fácil de mantener. El equipo central sintió que el pequeño impacto en el rendimiento valió la pena el compromiso a largo plazo.

Tengo algunas sugerencias sobre cómo podríamos abordar esto:

• [] crear un anuncio de rendimiento más atractivo y fácil de usar para Pixi, preferiblemente algo en ejemplos. Puede tener controles de grano fino para alternar funciones. Mantenga bunny-mark solo como una herramienta de prueba interna.
• [] continuar mejorando wiki para obtener sugerencias de rendimiento, lo que podría proporcionar demostraciones
• [] implementar pruebas de evaluación comparativa para Pixi, algo que sea coherente para medir
• [] verifique las caídas de rendimiento en las versiones más recientes como se indicó anteriormente

Ese problema debe solucionarse y luego las regresiones de rendimiento deben evitarse en el futuro.

Por supuesto, necesitamos mejorar la evaluación comparativa del rendimiento y, por supuesto, sería fantástico integrarlo en CI y, por supuesto, Pixi debe ser lo más rápido posible. Pero también necesitamos personas que estén dispuestas a enviar tiempo para ayudar a resolver estos problemas tan complejos. Si hay personas con una experiencia particular que realizan evaluaciones comparativas de rendimiento en diversos navegadores / hardware, ¡agradeceríamos contribuciones aquí!

¿Y tú, @tobireif? ¿Tiene experiencia en estas áreas? Muchas oportunidades para mejorar. Bienvenidos PR o esfuerzos aquí para perfilar, crear mejores pruebas, encontrar soluciones para hacer CI (Travis) con webgl, realizar búsquedas binarias en el historial de confirmaciones en busca de contribuciones de rendimiento negativo.

Además, me gustaría decir que bunnymark existía en varias versiones, pero hace unos meses le pedí a

Creo que la cantidad de texturas es la única tarea crítica para los puntos de referencia.

@bigtimebuddy

Gracias por preguntar. Tengo experiencia con la optimización del rendimiento, pero desafortunadamente no podré encontrar el tiempo para trabajar directamente en Pixi en el futuro previsible. Espero que mis contribuciones en forma de este (y otros) informes de temas aún sean apreciadas (también toman tiempo ...)

Ahora entiendo que "pixijs.github.io/bunny-mark" está diseñado para pruebas de rendimiento internas de desarrollo.

Entonces, si tuviera que mostrarle a alguien el gran desempeño de PixiJS (por ejemplo, cuando recomiendo Pixi para un proyecto específico), vincularía esto http://www.goodboydigital.com/pixijs/bunnymark/ ?
(en lugar de https://pixijs.github.io/bunny-mark/)
(Aunque puede haber demostraciones de rendimiento adicionales en el futuro, me gusta el bunnymark y hace el trabajo de manera impresionante).

(Creo que mostrar el rendimiento a los posibles usuarios de la biblioteca fue el propósito original de la primera / anterior marca de conexión, se publicó en las publicaciones del blog de GoodBoy, etc., no fue solo interno de desarrollo).

Por cierto, http://www.goodboydigital.com/pixijs/bunnymark/ usa ParticleContainer, pero una versión anterior de Pixi.

De nuevo, a todos ustedes:

¡Gracias por PixiJS!

@BuenoDigital

Actualmente estoy trabajando en la v5, ¡veré si podemos recuperar esos fps!

¡Suena genial! Esperando con ansias 😀

Quizás podría haber un bunnymark v5 (uno para mostrar el rendimiento de Pixi, como el bunnymark v3 existente http://www.goodboydigital.com/pixijs/bunnymark_v3/).

¡Hola! Cerrando este tema por ahora debido a su inactividad. No dude en darnos un toque si desea que se vuelva a abrir este número. Gracias 👍

No hay problema 😀

Pero aún sería genial si siempre hubiera una marca de conejo para la última versión respectiva, con el único propósito de mostrar el impresionante rendimiento de animación de PixiJS (algo diferente de la marca de conejo de prueba de humo utilizada por PixiJS-lib-developers) . Vincular una demostración de animación impresionante, como bunnymark, es útil para promocionar PixiJS, por ejemplo, en tweets. (El último bunnymark respectivo no debe ser más lento que los anteriores / debe admitir al menos la misma cantidad de conejitos a 60 fps que los bunnymarks anteriores. Probablemente usaría ParticleCointainer).

Si eso está dentro del alcance del proyecto PixiJS, vuelva a abrir (o podríamos pegar lo anterior en un nuevo ticket).

También hay varias líneas importantes en este boleto, por ejemplo, "implementar pruebas de evaluación comparativa para Pixi, algo que sea consistente para medir" por Matt Karl.

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

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.