Thanks for clearing up the terminology. I didn't know about "offscren buffering."
However, you say, "So instead of constantly pushing to the screen you buffer first off screen ( or in this case in memory ), then you push your frame to the display list." I don't think a copyPixel() call is going to perform faster just because you are applying it to a bitmap that isn't currently on the display list. I don't think that is what is meant by separating the rendering and code execution pipeline. Unless there is some behind the scenes stuff going on in the player, using an additional buffer and switching them is only going to add overhead. If someone knows the inner workings of the player better, please speak up. Just to be clear, the method that we currently use is to keep one main bitmap, which is on the display list. Every frame our update function calls a draw method on each one of our objects, which usually results in the object making a call to copyPixels() to add it's image into the scene. The background is usually called first, which serves to completely overwrite the previous frame. Using this method, we were able to have a hundred objects updating around the screen, blending with alpha transparency, etc, with extremely good performance on modest machines. You can see that game here: http://www.adultswim.com/games/ninebillion/index.html -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com On Wed Jul 11 14:01 , Samuel Agesilas wrote: > Ok... let's see if we can clear some of this up. I agree with Austin > about the definition of Double Buffering. This is very true it is a > technique used to remove artifacts from the screen. Most of this > happens effectively within the video hardware and not in the software > realm. What was originally asked is a technique called "off-screen > buffering". This technique is done in software when access to the > hardware is not permitted or not available. The process involves > writing the next frame in memory before pushing it to the screen. > This in flash is REALLY useful. Remember that in the new AVM2 the > rendering pipeline and code execution pipeline are completely > seperate. Which means whatever you do with code will always be faster > than whatever you push to the screen. So instead of constantly > pushing to the screen you buffer first off screen ( or in this case > in memory ), then you push your frame to the display list. > > Example... > In Saffron in order to allow for large models ( 600+ ) classes to be > loaded and scroll smoothly I use this technique extensively. I only > push to the screen what will be visible and the items that are not > remain in memory until they need to get pushed on the screen. The > same techniques is used in game programming. > > -sam > > On Jul 11, 2007, at 12:43 PM, Austin Haas wrote: > > > > > Double buffering isn't about performance. It's about drawing the > > next screen before the monitor does a vertical sync. The purpose of > > double buffering is to avoid graphic issues like tearing and > > shearing that occur when the screen is being updated at the same > > time as it's being drawn. > > > > You can use two buffers to simulate the double buffer technique, > > and there might be some performance gains there, and you might > > reduce the chances of tearing/shearing, but calling that double > > buffering would be an abuse of terminology, as that term already > > has an accepted meaning. You would be misleading anyone who was > > looking for a solution to the real problems that double buffering > > is intended to solve. > > > > I'd really like to know if there are performance gains with this > > technique in Flash. I thought that I tried it a while back, but > > abandoned the idea after seeing no real gains. Does anyone have any > > data or a live comparison? > > > > -austin > > > > -- > > Austin Haas > > Pet Tomato, Inc. > > http://pettomato.com > > > > On Wed Jul 11 13:22 , Keith Peters wrote: > >> I'm not sure what you mean by "true" double buffering, but you can > >> certainly draw to a bitmap that is not on the stage, and then just > >> draw > >> the content of that bitmap onto a visible one onEnterFrame. This does > >> give performance increases according to reports of those using the > >> technique. > >> > >> Austin Haas wrote: > >>> My understanding is that true double buffering is impossible in > >>> Flash. There would have to be support for it in the player. > >>> Environments that support double buffering usually either have a > >>> mechanism explicitly built in, or they at least allow you to draw > >>> to the screen between screen refreshes, so that you can avoid > >>> problems like tearing. I don't believe there is any way to get > >>> around tearing in Flash until they build in double buffering > >>> support. > >>> > >>> -austin > >>> > >>> > >> > >> > >> _______________________________________________ > >> osflash mailing list > >> [email protected] > >> http://osflash.org/mailman/listinfo/osflash_osflash.org > >> > > > > _______________________________________________ > > osflash mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
