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

Como ele se compara às versões anteriores?

Sim, é muito otimista, só uma vez vi um desktop que lidava com 100k coelhos multitextured a 75FPS. Eu também tenho 18 :)

Tente executar uma versão sem multi-texturização, havia um botão.

PIXI é otimizado para jogos "médios", mas tem muitos parâmetros, e você pode até mesmo escrever seu próprio renderizador superotimizado em cima da arquitetura pixi! Temos 10.000 vacas animadas (~ 16 quads cada), a 30FPS estáveis ​​em placas de vídeo antigas e Intel HD. Estágio extremo, uso de CPU muito baixo: https://www.youtube.com/watch?v=adixpp9CK_A. Quanto mais objetos estão mudando suas coordenadas, mais CPU é usada e pode lidar com casos em que tudo está se movendo a cada quadro em FPS suficiente. Espero lançar esse fork of pixi em um ou dois meses :)

Este fork será mesclado no master para tornar o pixi ótimo novamente?

Ivan, o que você consegue usando Pixi é muito impressionante. Ansioso para ver esse fork e aprender com ele. :)

@ jeebus3000 Não, será uma bifurcação de produção, exigirá um conhecimento profundo de pixi e webgl.

O número de configurações será alto:

1. Especifique como o formato de animação json é convertido em formato binário adequado para GPU. Pré-definido: apenas uma spritesheet, animação em flash, coluna vertebral. Todos com configurações diferentes (flutuações por instância, flutuações por quad)
2. pixi-display ++: enquanto pixi tem Container, haverá também Stage, Layer e Camera. Cada DisplayObject tem uma visualização que pertence a alguma camada e, para casos extremos (gameofbombs.com), haverá uma série de visualizações por objeto.
3. updateTransform () não é chamado a cada quadro, e há atualizações mais lentas do que no vanilla pixi. Não queremos que 10k elementos sejam chamados em JS quando eles não estiverem se movendo pelo mapa.
4. atlas em tempo real e texturas compactadas. Quando você desenvolve um jogo, precisa observar o que está acontecendo na memória de vídeo e como os atlas são formados. Atlas são feitos com configurações especiais em empacotadores de textura antes de serem compactados no formato resultante.

@bigtimebuddy

Como ele se compara às versões anteriores?

Quando clico em "v3.0.8", recebo o seguinte:

Idem para 3.0.9, 3.0.10.

Relatado em # 4023.

Com 3.0.11 obtenho 6fps.

Com 4.0.0 e 4.0.1 obtenho 23-24fps.

Daqui em diante, há uma regressão constante:

Com 4.1.0 e 4.1.1 obtenho 20-22fps.

Com 4.2.1 obtenho 19-20fps.

Com 4.4.4 e 4.5.1 obtenho 16-18 fps.

Espero que Pixi se torne mais rápido novamente.

cc @GoodBoyDigital

@ivanpopelyshev Isso é impressionante! Mas preciso que o PixiJS padrão seja extremamente rápido (e meus casos de uso costumam se parecer com marcas de coelho).

Talvez possa haver um teste (que é sempre executado) que verifica se o código Pixi mais recente é tão rápido (ou mais rápido) quanto o mais rápido das versões anteriores.

Além disso, talvez a marca do coelho deva ser alterada para usar pequenos coelhos de textura única se isso ajudar no desempenho. Pode haver uma opção para coelhos maiores / multi-texturizados (e até mesmo animados) (com uma contagem padrão muito menor). (Essas opções exigiriam botões adicionais que não existem atualmente.)

Se depois de tudo isso a contagem padrão de 100000 ainda for muito otimista, ela deve ser alterada para algo significativamente menor, de forma que quando alguém for enviado para a marca de coelho PixiJS (e for executado com os padrões), não fará com que PixiJS pareça ruim. Em vez da baixa taxa de quadros atual, as pessoas deveriam ver bons e suaves 60fps.

@tobireif você tem apenas uma configuração lá: contagem de textura no spriterenderer. Faça um grande atlas 4k x 4k ou 8k x 8k e será muito melhor do que multitextura.

Você tem que testar quais configurações do webgl seus usuários têm, otimizações não são possíveis sem essa informação. Como exemplo, sabemos que 99% tem plugins de texturas 4k e texturas flutuantes, e o usamos muito, enquanto o renderizador de pixi vanilla não.

No meu caso, pixi é como um padrão para renderizadores melhores adequados para tarefas específicas.

@ivanpopelyshev

contagem de textura no spriterenderer. Faça um grande atlas 4k x 4k ou 8k x 8k e será muito melhor do que multitextura.

Se isso ajuda no desempenho do que deveria ser implementado no PixiJS bunnymark, certo?

Da versão 4.0.1 para 4.5.1, PixiJS tornou-se mais lento - a taxa de quadros do bunnymark foi de 23-24fps para 16-18fps. Esse problema precisa ser corrigido e, em seguida, as regressões de desempenho precisam ser evitadas no futuro (por exemplo, usando um teste de CI).

No meu caso, pixi é como um padrão para renderizadores melhores adequados para tarefas específicas.

Preciso que o "vanilla PixiJS" seja extremamente eficiente e suspeito que outros usuários do Pixi JS também tenham.

Sim, precisamos de mais um campo de texto na configuração, como "contagem de textura:". Quanto a 4.0.1-4.5.1, acho que temos que entender primeiro se sua CPU ou GPU desotimizamos.

@tobireif , esse é um bom ponto! Provavelmente deveríamos começar em algo bem mais baixo - talvez 1000? É um ajuste fácil @bigtimebuddy?

Com relação ao desempenho, estamos basicamente trocando mais flexibilidade por energia. Também existe um certo preconceito no conteúdo estático na versão atual do pixi (já que a maioria das coisas tende a não se mover!)

Bunnymark corre muito mais rápido se você usar um recipiente de partículas :)

Mas é um bom grito, no momento estou trabalhando na v5, vou ver se podemos conseguir esse fps de volta!

@ivanpopelyshev Eu voltei para a velha forma 4.0.0 de vinculação de textura na v5 (menos mágica - eu vagueio se isso ajudar!)

@GoodBoyDigital que vai ajudar. a encadernação de textura inteligente funcionava SOMENTE em uma textura única, todo o uso de multitextura era um problema.

Ei pessoal, que versão convertemos para ES6? Eu conheço aquele hit perf um pouquinho!

@GoodBoyDigital

A marca de coelho é uma coisa. É importante que seja rápido, porque é para mostrar que Pixi é rápido. E por ser um exemplo de desempenho (cujas pessoas de origem podem estudar e parafrasear), ele deve exibir todas as otimizações lib-user possíveis e sensatas. E a contagem de coelhos ainda deve ser um número impressionante, por exemplo, 40000 ou 50000 (por exemplo, a contagem mais alta que traz 60fps com as melhorias mencionadas neste tíquete e com Pixi versão 5 em, por exemplo, minha máquina / Ivan).

Mas, independentemente do código da marca de coelho, Pixi em si precisa ser extremamente rápido, como todos concordamos.

Espero que todos possam alcançar e manter um ótimo desempenho!

Também existe um certo preconceito no conteúdo estático na versão atual do pixi (já que a maioria das coisas tende a não se mover!)

Sempre que uso o Pixi, a maioria das coisas se move 😀

Bunnymark corre muito mais rápido se você usar um recipiente de partículas :)

Portanto, o código da bunnymark deve usar um contêiner de partículas, certo?

No momento, estou trabalhando na v5, verei se conseguimos recuperar o fps!

Excelente! 👍

Não concordo com o propósito assumido da marca de coelho aqui. O objetivo não é necessariamente mostrar algo rodando a 60fps. Usamos isso como uma forma de comparar o desempenho relativo de releases / dev e como um teste de fumaça. Até que tenhamos boas maneiras de benchmarking, esta é a nossa melhor ferramenta agora para medir os impactos de desempenho. 100000 bunny foi intencional para realmente empurrar o renderizador para o lugar onde ele estaria lutando. Se quisermos mostrar o quão rápido Pixi é, isso não é a coisa certa para o trabalho. Eu teria criado algo usando o ParticleCointainer, como ~ Ivan ~ Mat sugeriu.

Sabemos que houve uma pequena queda de desempenho na v4.1+ e muito disso foi porque reescrevemos a base de código no ES6 para torná-la mais sustentável. A equipe principal sentiu que o pequeno impacto no desempenho valia a pena a longo prazo.

Tenho algumas sugestões sobre como podemos resolver isso:

• [] criar um anúncio de desempenho mais sexy e amigável para Pixi, de preferência algo em exemplos. Pode ter controles de granulação fina para alternar recursos. Mantenha a marca de coelho apenas como uma ferramenta de teste interna.
• [] continuar a melhorar o wiki para dicas de desempenho, potencialmente fornecendo demonstrações
• [] implementar testes de benchmarking para Pixi, algo que é consistente para medir
• [] verifique se o desempenho cai nas versões mais recentes, conforme declarado acima

Esse problema precisa ser corrigido e, em seguida, as regressões de desempenho precisam ser evitadas para o futuro

É claro que precisamos melhorar o benchmarking de desempenho e, claro, seria ótimo integrá-lo ao CI, e é claro que o Pixi precisa ser o mais rápido possível. Mas também precisamos de pessoas dispostas a enviar tempo para ajudar a resolver esses problemas muito complexos. Se houver pessoas com uma experiência específica fazendo benchmarks de desempenho em diversos navegadores / hardware, gostaria de receber contribuições aqui!

E você, @tobireif? Você tem experiência nessas áreas? Muitas oportunidades para melhorar. Bem-vindo PRs ou esforços aqui para criar perfis, criar melhores testes, encontrar soluções para fazer CI (Travis) com webgl, fazer buscas binárias no histórico de commits procurando por contribuições de desempenho negativo.

Além disso, gostaria de afirmar que o bunnymark existia em várias versões, mas alguns meses atrás eu pedi a @bigtimebuddy para ajudar com isso, eu sou péssimo em fazer interfaces :) Ele já implementou uma série de recursos extras nele, eu estou feliz do jeito que está.

Eu acredito que o número de texturas é a única tarefa crítica para benchmarks.

@bigtimebuddy

Obrigado por perguntar. Tenho experiência com otimização de desempenho, mas infelizmente não vou conseguir encontrar tempo para trabalhar diretamente no Pixi em um futuro próximo. Espero que minhas contribuições na forma deste (e de outros) relatórios de problemas ainda sejam bem-vindas (também levam tempo ...)

Agora eu entendo que "pixijs.github.io/bunny-mark" se destina ao teste de desempenho interno do dev.

Então, se eu fosse mostrar a alguém o grande desempenho do PixiJS (por exemplo, ao recomendar o Pixi para um projeto específico), eu colocaria este link http://www.goodboydigital.com/pixijs/bunnymark/ ?
(em vez de https://pixijs.github.io/bunny-mark/)
(Embora possa haver demonstrações de desempenho adicionais no futuro, eu gosto da marca de coelho, e ela faz um trabalho impressionante.)

(Eu acho que mostrar o desempenho para usuários lib em potencial era o propósito original do primeiro / anterior bunnymarks, foi postado em posts do blog GoodBoy etc, não era apenas dev-internal.)

BTW, http://www.goodboydigital.com/pixijs/bunnymark/ usa ParticleContainer, mas uma versão Pixi mais antiga.

Novamente, para todos vocês:

Obrigado pelo PixiJS!

@GoodBoyDigital

No momento, estou trabalhando na v5, verei se conseguimos recuperar o fps!

Parece bom! Ansioso por isso 😀

Talvez pudesse haver uma marca de coelho v5 (uma para mostrar o desempenho de Pixi, como a marca de coelho v3 existente http://www.goodboydigital.com/pixijs/bunnymark_v3/).

Olá! Fechando esta edição por enquanto devido à sua inatividade. Sinta-se à vontade para nos dar uma olhada se quiser que esta edição seja reaberta. Obrigado 👍

Não tem problema 😀

Mas ainda seria ótimo se sempre houvesse uma marca de coelho para o respectivo lançamento mais recente, com o único propósito de mostrar a impressionante performance de animação do PixiJS (algo diferente da marca de teste de fumaça usada por PixiJS-lib-developers) . Vincular uma demonstração de animação impressionante, como a bunnymark, é útil ao promover PixiJS, por exemplo, em tweets. (A respectiva marca de coelho mais recente não deve ser mais lenta que as anteriores / deve suportar pelo menos a mesma quantidade de coelhos a 60 fps que a marca de coelho anterior. Provavelmente usaria o ParticleCointainer.)

Se isso está no escopo do projeto PixiJS, por favor, reabra (ou podemos colar o acima em um novo tíquete).

Também existem várias linhas importantes neste bilhete aqui, por exemplo, "implementar testes de benchmarking para Pixi, algo que é consistente para medir" por Matt Karl.

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

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Abra um novo problema para bugs relacionados.