[AS3] Speed issue - one large copyPixels vs. 4 smaller ones

Subscribe to [AS3] Speed issue - one large copyPixels vs. 4 smaller ones 8 posts

avatar for Ace_Blue Ace_Blue 1130 posts
Flag Post

I want to draw (blit) a frame around my screen (a bitmap). Would it be faster to blit it all at once, so it has the width and height of the screen but is mostly transparent pixels, or would it be faster to blit only the opaque parts at the top, bottom, left and right edges? The first way involves a single copyPixels() call on width * height pixels, the other involves four distinct copyPixels() calls on width * ~10% height (twice, for top and bottom) and ~80% height * ~10% width (twice, for left and right) so about 40% of the pixel count.

Also, am I splitting hairs and it doesn’t make any difference?

 
avatar for Senekis93 Senekis93 4090 posts
Flag Post

If it’s a single object, moving its x and y is faster; blitting is good when dealing with tons of objects.

And… i haven’t tested it, but I’m gonna guess that a single call would be faster, as any gain you may get from copying less pixels would be nullified by the cost of 4 function calls vs a single one.

E: You could simply call both methods a lot of times and see which runs faster.

E2: If you’re only going to do this once, then it’s completely irrelevant.

 
avatar for Ace_Blue Ace_Blue 1130 posts
Flag Post

I’m doing it once every (game) frame. I’ve thought about putting it on a separate bitmap since it’s 1) static 2) always present and 3) always on top of the display, so I would only have to create it once per game and then I’d be done with it, but I’m trying to avoid a proliferation of objects on the display list. Since I already have a bitmap that covers the entire span of the flash window (the game screen display), I figured I might as well blit on it.

 
avatar for Senekis93 Senekis93 4090 posts
Flag Post

Well, yeah, if your concern is to have as few display objects as possible, go ahead and copy it over your bitmap, but it’d be way better for performance to have it as a different bitmap instead of copying it over every frame.

 
avatar for truefire truefire 3015 posts
Flag Post

The second method will be faster unless your stage is like 10×10 pixels.

Assuming 640×480, your stage is 307,200px. If you’re shaving off 60%, that’s ~180,000 pixel sets (/transparency checks) your saving. WAY more then the overhead of three (4 – 1) function calls.

 
avatar for Drakim Drakim 1183 posts
Flag Post

truefire speaks the truth

 
avatar for Ace_Blue Ace_Blue 1130 posts
Flag Post

Thanks for all the replies. I’m using an 800×600 window and the ‘frame’ is a border about 20 pixels wide, so it’s even more extreme than the case Truefire considered (more than 400k fully transparent pixels, 88% of the surface area). Obviously then, I went ahead and implemented the single copyPixels() call method, because it was easier, and I’m a lazy bum. On the other hand, I got no lag, so yay me I guess.

Edit: \/ I know, sorry I wasn’t clear. I was saying that, in spite of all the smart, informed people in this thread telling me about better ways to do this, I still went with the most wasteful method because I’m lazy, but it’s not lagging yet. Since I’m still adding to the display I may have to revise my laziness later on if the game starts lagging.

 
avatar for truefire truefire 3015 posts
Flag Post

I was saying the four-copyPixels method is faster…