Wednesday, 28 March 2012

Practical optimisation

While browsing on Wonderfl to see how my cross product shader was doing I came across someone else's code, the evocatively named "forked from: flash on 2012-3-23". Running it I noticed it was slow: it was not doing much but got slower and used more CPU as it ran. So I decided to look into it.


The result was my "forked from: forked from: flash on 2012-3-23". Wonderfl indicates the chain of forks/dependencies in both the name and the comments at the top of the source code, and although these can be edited it's nice to leave them in if the code depends on the code it's forked from.


What I did was optimised it. The initial code was repeatedly calling drawCircle with random colours, placement and size. But it was doing so in the same Graphics object, adding more and more circles which Flash slowly bogged down over. I changed that to clear the Graphics object after using draw to render them to a BitmapData, for a massive speedup. More importantly doing it like this does not slow down over time.


The other main optimisation was using the best graphics objects. For the drawing I used the most lightweight Graphics rendering object, a Shape. And to contain the BitmapData the best thing was a Bitmap, which is the only thing added to the scene. Apart from that I get the stage width and height once, but more to make the code more readable. And I sped it up by a factor of 4: may as do something with the extra performance.


I use similar optimisations extensively in the game I'm working on. It would be fair to say that almost all of the graphics are done this way, as I can think of only one thing onscreen that's not either generated using BitmapData draw() or passed to it after it's drawn. The game would not be possible without it.

No comments:

Post a Comment