Friday, May 23, 2008
A moment of clarity regarding the DisplayList
Friday, May 23, 2008 
I just had a moment of clarity, and a way to program things that can in reality be technically more inefficient yet run a whole lot smoother... all based on the DisplayList. This is something that I can't believe I haven't discovered yet or really understood until now through all my use and research on it.
I was coding up an application where a lot of pretty complex math was being computed for various sprites. Proximity of sprites to other sprites, angle from another sprite, relationship to the mouse position, etc. Everything was working perfectly. However, I had forgotten to add some sprites to the display list.
Well... that opened my mind up a little bit. It's kind of like setting the visibility to false in AS2. Kinda.
The largest slowdown for the Flash Player (generally) is rendering. It eats up a lot of cycles. So you don't necessarily have to add things to the display list to use them. In all the examples I've ever seen, every time you create a display object, it was added to the list. Makes sense, especially for most tutorials.
However, my omission by mistake opened up a whole TON of power that I was overlooking.
So today, I was checking out some work by a co-worker, and he has this totally sweet class that does stuff with BitmapData. Well, I remembered that mistake I had made earlier that worked, and we commented out a line where a large display object was getting added to the list.
The BitmapData stuff worked just as expected, driven by the display object not on the display list, and the speed jumped up by at least 50% (in the animation of the representation in the bitmap). Whoa.
It's easy to assume you need to add things to the list. Now, I could have a super long list of stuff that I am scrolling around, and instead of having the player render ANY of it, I can use bitmap data of a portion of it and have the player render that instead... so behind the scenes being inefficient (not clipping the object dynamically, etc.) but yet gain a lot on the other end of it.
I previously had a different mindset in regards to the display list. Now I see where the true power really lies, something I should have seen long ago. I feel a little embarrassed about it, but now that I know, the way I develop is going to change for the better. More speed. A little more difficult because you almost need to think in another dimension while coding & testing, but so worth it.
Simple changes like this speed up performance by large amounts (when it makes sense).
Thanks for that little mistake, I now think I know a whole lot more about how to properly use the DO as it was intended.
I was coding up an application where a lot of pretty complex math was being computed for various sprites. Proximity of sprites to other sprites, angle from another sprite, relationship to the mouse position, etc. Everything was working perfectly. However, I had forgotten to add some sprites to the display list.
Well... that opened my mind up a little bit. It's kind of like setting the visibility to false in AS2. Kinda.
The largest slowdown for the Flash Player (generally) is rendering. It eats up a lot of cycles. So you don't necessarily have to add things to the display list to use them. In all the examples I've ever seen, every time you create a display object, it was added to the list. Makes sense, especially for most tutorials.
However, my omission by mistake opened up a whole TON of power that I was overlooking.
So today, I was checking out some work by a co-worker, and he has this totally sweet class that does stuff with BitmapData. Well, I remembered that mistake I had made earlier that worked, and we commented out a line where a large display object was getting added to the list.
The BitmapData stuff worked just as expected, driven by the display object not on the display list, and the speed jumped up by at least 50% (in the animation of the representation in the bitmap). Whoa.
It's easy to assume you need to add things to the list. Now, I could have a super long list of stuff that I am scrolling around, and instead of having the player render ANY of it, I can use bitmap data of a portion of it and have the player render that instead... so behind the scenes being inefficient (not clipping the object dynamically, etc.) but yet gain a lot on the other end of it.
I previously had a different mindset in regards to the display list. Now I see where the true power really lies, something I should have seen long ago. I feel a little embarrassed about it, but now that I know, the way I develop is going to change for the better. More speed. A little more difficult because you almost need to think in another dimension while coding & testing, but so worth it.
Simple changes like this speed up performance by large amounts (when it makes sense).
Thanks for that little mistake, I now think I know a whole lot more about how to properly use the DO as it was intended.
Comments:
There are currently 3 Comments:
