Jump to content

Rough attempt at a Phaser "BunnyMark"


Recommended Posts



Since I'm a relative n00b here, I made a quick attempt to replicate the Pixi bunnymark (http://www.goodboydigital.com/pixijs/bunnymark/)


it's on the sandbox



It's important to understand that Pixi & Phaser rendering models aren't the same. Although I am currently trying to understand where the overheads are. The Phaser 3 BunnyMark test is much different.. rendering 200k+  items using different techniques (Canvas vs WebGL differences maybe), and that Rich and co are putting in a lot of work to improve the rendering.. this is more here to understand the sort of performance to expect from Phaser using unoptimized basics. I'd be interested to know if there's a better technique for getting sprites to render faster (ignoring pooling for now) .. eg bitmapdata copyRect etc?


What's interesting is my demo seems to run faster with 8000 Sprites than it does with 4000. Possibly this has something to do with garbage collection?


I know you're not really meant to add any new objects during the "update" loop... so you're going to get slowdowns here anyway.


Anyway it's there for people to mess around with, I just wanted to get the basic code up. 





PS does anybody know why game.input.onDown.add and game.input.onUp.add don't respond on iPad? I thought those covered touch as well.

Link to comment
Share on other sites

but what about an event?


i added this in the update loop in the meantime, but I thought there'd be a normal callback 

    if(!isAdding && game.input.activePointer.isDown) { onInputDown() }    if(isAdding && !game.input.activePointer.isDown) { onInputUp() }

works on iPad now thanks DonF

Link to comment
Share on other sites

keep adding them MichaelID.. to about 8000, does FPS go up again?

Dumb question: is it possible that you were just seeing the performance dip of allocating the sprites, and that performance at 4000 goes up after a few seconds too?
Link to comment
Share on other sites

yes I'm sure that's what it is., but it didn't seem to peak until ~8000


with ~4500 sprites it's hovering ~40-50fps, even if i just leave it


then when i add another batch it picks up again


What I don't get is why it doesnt pick back up to ~60fps with that 4500.

Link to comment
Share on other sites

There are a great many complications with this sort of test, the most important being that browsers do all sorts of stuff behind the scenes... dynamic optimisations sometimes make code triple in speed after about 30-60 seconds of run time.


In order to test drawing speed for Phaser 3 I've been building incredibly simple test beds, and feeding the graphics to webgl with as few pieces of code as possible.  Even then I find that sometimes I can get 250K bunnies and on other days, with no apparent change in the environment, it will cap out at 175k (a more than 25% difference).


Unfortunately the nature of Phaser (being a complex and comprehensive API) is that you cannot do "simple" tests with it.  Even the most basic implementation of sprites-on-screen has a ton of support code related to handling all the many different graphic sources and purposes that the system might be used for.  With this amount of code the browser performance becomes somewhat random (in my experience) and optimisation of your demo code is unlikely to gain true benefits across all browser types and for all circumstances.


If you absolutely need the fastest performance, you really have to use a very low level API... of course that means you won't get all the benefits that Phaser provides and you'll have to spend a lot more time finding solutions to the problems raised.


However, thanks #jmp909 for making this test... I'll be sure to include it into the tests for Phaser 3 because even with such erratic behavior, I can hope that the new renderer will be significantly faster :)

(Note: any speed improvement will most likely come from the tighter bonding between the new renderer and Phaser 3, PIXI is already extremely well optimised for pure drawing power)


EDIT: I just ran the demo, I think that environment (dynamic code editing) has a fairly heavy performance impact... pretty sure Rich warned me about that just a few days ago.  Try it locally or on a clean web-page and see if there's a big difference (or at least a more consistent response).

Link to comment
Share on other sites


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...