pretty easy to compare the speeds. create two bitmaps. put one on the
display list. perform a bunch of operations on each one, note the time.
the following tests setpixel, and shows around a 13% performance
increase for the bitmap not on the display list.
package {
import flash.display.Sprite;
import flash.utils.getTimer;
import flash.display.Bitmap;
import flash.display.BitmapData;
public class BlitTest extends Sprite
{
public function BlitTest()
{
var bmp1:BitmapData = new BitmapData(500, 500, true, 0);
var bmp2:BitmapData = new BitmapData(500, 500, true, 0);
var holder:Bitmap = new Bitmap(bmp2);
addChild(holder);
var start:int
var i:uint;
start = getTimer();
for(i = 0; i < 1000000; i++)
{
bmp1.setPixel(Math.random() * 500, Math.random() * 500,
Math.random() * 0xffffff);
}
trace(getTimer() - start);
start = getTimer();
for(i = 0; i < 1000000; i++)
{
bmp2.setPixel(Math.random() * 500, Math.random() * 500,
Math.random() * 0xffffff);
}
trace(getTimer() - start);
}
}
}
Samuel Agesilas wrote:
> Yea... I agree with you on the copyPixel() I don't believe that doing
> it offscreen offers any performance improvements. But right now the
> bottleneck is definitely the displayList API and I believe it's as
> fast as it's ever going to be in the software realm. The next step is
> Hardware acceleration. Where are starting to see Adobe go that route
> with the latest beta of the Flash 9 player using HW acceleration for
> Video Playback. Hopefully we will see more of this for the
> displayList API.
>
> btw... The games is great!! Very nice work!!
>
> -sam
>
>
> On Jul 11, 2007, at 2:26 PM, Austin Haas wrote:
>
>
>> 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
>>
>
>
> _______________________________________________
> 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
