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

How does it compare to previous versions?

Yes, its very optimistic, I only once saw a desktop that handled 100k multitextured bunnies at 75FPS. I have 18 too :)

Try run a version without multi-texturing, there was a button.

PIXI is optimized for "average" game, but it has many parameters, and you can even write your own super-optimized renderer on top of pixi architecture! We have 10000 animated cows (~16 quads each), at stable 30FPS on old videocards and intel HD. Extreme stage, very low CPU usage: https://www.youtube.com/watch?v=adixpp9CK_A . The more objects are changing their coords, the more CPU is used, and it can handle cases where everything is moving every frame at sufficient FPS. I hope to release that fork of pixi in a month or two :)

Will this fork be merged in the master to make pixi great again?

Ivan what you achieve using Pixi is very impressive. Look forward to seeing this fork and learning from it. :)

@jeebus3000 No, it'll be a production fork, it will require deep knowledge of pixi and webgl.

The number of settings will be high:

1. Specify how your json animation format converts to binary format suitable for GPU. Pre-defined: just a spritesheet, flash animation, spine. All with different settings (floats per instance, floats per quad)
2. pixi-display++: while pixi has Container, there will be also Stage, Layer and Camera. Every DisplayObject has a View that belongs to some layer, and for extreme cases (gameofbombs.com) there'll be a number of views per object.
3. updateTransform() is not called every frame, and there are more lazy updates than in vanilla pixi. We dont want 10k elements to be called in JS when they're not moving across the map.
4. realtime atlases and compressed textures. When you develop game, you have to look at what's happening in videomemory and how atlases are formed. Atlases are made with special settings in texture packers before they compressed in the resulting format.

@bigtimebuddy

How does it compare to previous versions?

When I click "v3.0.8" I get this:

Ditto for 3.0.9, 3.0.10.

Reported at #4023 .

With 3.0.11 I get 6fps.

With 4.0.0 and 4.0.1 I get 23-24fps.

From here on there's constant regression:

With 4.1.0 and 4.1.1 I get 20-22fps.

With 4.2.1 I get 19-20fps.

With 4.4.4 and 4.5.1 I get 16-18fps.

I hope Pixi will become faster again.

cc @GoodBoyDigital

@ivanpopelyshev That's impressive! But I need stock PixiJS to be extremely fast (and my use cases often do look like bunnymarks).

Perhaps there could be a test (that is always run) which checks whether the latest Pixi code is as fast (or faster) as the fastest of the previous versions.

Also, perhaps the bunnymark should be changed to use small single-texture bunnies if that helps perf. There could be an option for larger / multi-textured (and even animated-in-itself) bunnies (with a much lower default count). (These options would require additional buttons which aren't there, currently.)

If after all this the default count of 100000 is still too optimistic it should be changed to something significantly lower, so that when someone gets sent to the PixiJS bunnymark (and it gets run with the defaults) it won't make PixiJS look bad. Instead of the current low framerate people should see a nice and smooth 60fps.

@tobireif you have only one setting there: texture count in spriterenderer. Make one big atlas 4k x 4k or 8k x 8k and it'll be much better than multitexture.

You have to test what webgl settings your users have, optimizations aren't possible without that info. As an example, we know that 99% have 4k textures and float textures plugin, and we use it a lot, while vanilla pixi renderer does not.

In my case pixi is like a boilerplate for better renderers suited for specific tasks.

@ivanpopelyshev

texture count in spriterenderer. Make one big atlas 4k x 4k or 8k x 8k and it'll be much better than multitexture.

If that helps perf than it should get implemented in the PixiJS bunnymark, right?

From version 4.0.1 to 4.5.1, PixiJS became slower - the bunnymark framerate went from 23-24fps to 16-18fps . That issue needs to get fixed, and then perf regressions need to get prevented for the future (eg using a CI test).

In my case pixi is like a boilerplate for better renderers suited for specific tasks.

I need "vanilla PixiJS" to be extremely performant, and I suspect other Pixi JS users do as well.

Yeah, we need one more text field in setup, like "texture count: ". As for 4.0.1-4.5.1 , I think we have to understand first whether its CPU or GPU we deoptimized.

@tobireif , thats a good point! We should probably start it on something way lower - maybe 1000? Is that an easy tweak @bigtimebuddy?

With regards to perf, we are basically trading more flexibility for power. Theres a bit of a bias on static content in the current version of pixi too (as most things tend not to move!)

Bunnymark runs way faster if you use a particle container :)

But its a good shout, I'm currently working on v5, I will see if we can get that fps back up!

@ivanpopelyshev I reverted back to the old way 4.0.0 way of texture binding in v5 (less magic - I wander if that will help!)

@GoodBoyDigital that will help. smart texture binding worked ONLY in single-texture thing, all multitexture usage was pain with it.

Hey chaps, which version did we convert to es6? I know that hit perf a tiny bit!

@GoodBoyDigital

The bunnymark is one thing. It is important that it's fast, because it's supposed to show that Pixi is fast. And because it's a perf example (whose source people might study and paraphrase) it should exhibit all possible & sensible lib-user-side optimizations. And the bunny count should still be an impressive number, eg 40000 or 50000 (eg the highest count that brings 60fps with the improvements mentioned in this ticket and with Pixi version 5 on eg my/Ivan's machine).

But regardless of the bunnymark code Pixi itself needs to be extremely fast, as we all agree.

I hope you all can achieve and maintain great perf!

Theres a bit of a bias on static content in the current version of pixi too (as most things tend not to move!)

Whenever I use Pixi, most stuff moves 😀

Bunnymark runs way faster if you use a particle container :)

Thus the bunnymark code should use a particle container, right?

I'm currently working on v5, I will see if we can get that fps back up!

Great! 👍

I disagree with what is the assumed purpose of bunny-mark here. The goal is to not necessarily show something running at 60fps. We use this as a way to compare the relative performance of releases/dev and as a smoke-test. Until we have good ways for benchmarking, this is our best tool right now for gauging performance impacts. 100000 bunny was intentional to really push the renderer to place where it would be struggling. If we want to show-off how fast Pixi is, this is not the right thing for the job. I would have authored something using ParticleCointainer, as ~Ivan~ Mat suggested.

We know there was a slight performance hit in v4.1+ and much of this was because we rewrote the code base in ES6 to make it more maintainable. The core team felt like the small performance hit was worth the trade-off long term.

I have a few suggestions for how we might address this:

• [ ] create a sexier, user-friendly performance advertisement for Pixi, preferably something in examples. Might have fine grain controls for toggling features. Keep bunny-mark as an internal testing tool only.
• [ ] continue to improve wiki for performance tips, potentially providing demos
• [ ] implement benchmarking tests for Pixi, something that's consistent to measure
• [ ] verify performance drops on the most recent versions as stated above

That issue needs to get fixed, and then perf regressions need to get prevented for the future

Of course we need to improve benchmarking of performance, and of course it would be terrific to integrate into CI, and of course Pixi needs to be as fast as possible. But we also need people who are willing to send time helping solve these very complex problems. If there are people out there with a particular experience doing performance benchmarks across diverse browsers/hardware, would welcome contributes here!

What about you, @tobireif? Do you have expertise in these areas? Lots of opportunities to improve. Welcome PRs or efforts here to profile, to create better tests, to find solutions for doing CI (Travis) with webgl, to do binary searches on the commit history looking for negative-performance contributions.

Also, I'd like to state that bunnymark existed in multiple versions, but a few months ago I asked @bigtimebuddy to help with it, I'm terrible at making interfaces :) He already implemented a number of extra features in it, I'm happy the way it is.

I believe that number of textures is the only task that is critical for benchmarks.

@bigtimebuddy

Thanks for asking. I do have experience with performance optimization, but unfortunately I won't be able to find the time to directly work on Pixi in the foreseeable future. I hope that my contributions in the form of this (and other) issue reports still are appreciated (they take time as well ...)

I now understand that "pixijs.github.io/bunny-mark" is intended for dev-internal perf testing.

So if I were to show someone the great perf of PixiJS (eg when recommending Pixi for a specific project), I'd link this http://www.goodboydigital.com/pixijs/bunnymark/ ?
(instead of https://pixijs.github.io/bunny-mark/ )
(Although there might be additional perf demos in the future, I do like the bunnymark, and it does the job impressively.)

(I think that showcasing performance to potential lib users was the original purpose of the first/earlier bunnymarks, it was posted in GoodBoy blog posts etc, it wasn't just dev-internal.)

BTW, http://www.goodboydigital.com/pixijs/bunnymark/ uses ParticleContainer, but an older Pixi version.

Again, to you all:

Thanks for PixiJS!

@GoodBoyDigital

I'm currently working on v5, I will see if we can get that fps back up!

Sounds great! Looking forward to it 😀

Perhaps there could be a v5 bunnymark (one for showcasing Pixi's perf, like the existing v3 bunnymark http://www.goodboydigital.com/pixijs/bunnymark_v3/ ).

Hi there! Closing this issue for now due to its inactivity. Feel free to give us a poke if you would like this issue reopened. Thanks 👍

No problem 😀

But it would still be great if there'd always be a bunnymark for the respective latest release, with the sole purpose of showcasing the impressive animation performance of PixiJS (something different from the smoke-test-bunnymark used by PixiJS-lib-developers). Linking an impressive animation demo such as the bunnymark is helpful when promoting PixiJS, eg in tweets. (The respective latest bunnymark should not be slower than the previous ones / should support at least the same amount of bunnies at 60fps as previous bunnymarks. It would probably use ParticleCointainer.)

If that's in scope for the PixiJS project, please re-open (or we could paste the above into a new ticket).

Also there are various important lines in this here ticket, eg " implement benchmarking tests for Pixi, something that's consistent to measure" by Matt Karl.

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

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.