performance tweaking - Rasterizing edges question

[Guest]

I am trying to profile my game (using Adobe Scout) and the vast majority of the execution time is spent in 'DisplayList Rendering > Raterizing edges'.

My game consists mainly of a large background bitmap drawn with smoothing enabled - with other stuff drawn ontop. As a player moves around the map, I alter the ScrollRect on the bitmap to draw only the region within the bounds of the stage.

From what I'm seeing, it appears as though when I move the scrollRect that flash is spending a lot of time 'rasterizing edges'. It performs much better if I set the stage quality to low, which suggests that the bitmap is being processed/smoothed whenever I move the scrollRect.

Am I right in thinking this is not necessary? Surely the bitmap can be drawn once with smoothing enabled (it doesn't change) and then can be moved around the screen without the need for any rasterization?

Is there something I can do about this?

[kglad]

skip to displaylist rendering: http://www.adobe.com/devnet/scout/articles/understanding-flashplayer-with-scout.html

to get better performance, you should consider blitting or, at least, partial blitting.

[sinious]

Have you attempted to simply move the bitmap itself without any masking? It's still fully in memory with scrollRect and there may be some behind the scenes optimizations to clip edges of the display (auto viewport culling). I haven't tried this myself but I'm curious. I'm sure loading a 4096x4096 (ATF of course) and panning it around would easily reveal which is faster.

edit:

He always beats me . A larger scrollRect is a good idea as well. It would cut down on the rect changes drastically.

To throw a bone in there, not ideal but if it's really large textures you might want to consider handing the job to Stage3D.. Starling could easily offload all that work. I still blit in one application but every time I releave the CPU and stop blitting it makes the entire application feel much faster.

[Guest]

I've tried without any ScrollRect and the performance seems to be slightly worse unfortunately.

In regards to blitting, do you mean creating a bitmapData object the size of the stage and on each frame populating the bitmapData with copyPixel calls?

[kglad]

yes.

[sinious]

I wonder how differently under the hood blitting vs scrollRect is handled. Essentially that's all a scrollRect is anyhow. Clipped data.. Any idea kglad?

[kglad]

no, i don't know.  i'm working on a way to test.

[Guest]

I've tried using the method you suggested. It is definitely faster when moving around bitmaps on the screen.

I still have a problem though when drawing movie clips ontop of my blitted bitmap, again with rasterizing edges taking a very large chunk of execution time.

My display list is like this:

       1 -> canvasBitmap

        2 -> animationLayer

where canvasBitmap is a bitmap with a bitmapData object called canvas.

On each frame, I update the canvas using copyPixels like so:

    var rect:Rectangle = new Rectangle(0,0,stage.stageWidth, stage.stageHeight);

     var point:Point = new Point();

    // on Enter frame

    canvas.copyPixels(backgroundBitmap, rect, point);

     canvas.copyPixels(mapTilesBitmap, rect, point);

The animation layer ontop contains around 7 animated MovieClips. When a lot of them are currently visible on the stage, my FPS drops quite a bit, with rasterizing edges taking 15-20ms

If I keep the canvas blank, the movieClips by themselves take less than a 1-2 ms to render on each frame.

any ideas? I can't really blit the movieClips as some of them have many frames.

[kglad]

movieclips that change frames are problematic.  it doesn't take many frames/rotations/alphas etc to make blitting impractical because of memory issues, and there's nothing else that can be done, other than the obvious:  decrease the number of frames in those movieclips.  

are you making an air for desktop game?  air for mobile game?  web-based game?

[Guest]

web based at the moment

The canvasBitmap is fast on it's own, the animation layer is fast on its own but together they are slow

[kglad]

how large are your movieclips (w x h) in px?  how many frames in your movieclips?  how many movieclips?

are you changing any of the movieclips scale, rotation or alpha?

[Guest]

The movieClips range from 25x25 to 200x200.

Some have 30 frames, some hundreds (although a lot of the frames are identical)

There might be up to 15 - 20 movieClips to display

The scale of each moveClip is changed when the user zooms in/out

[kglad]

noone has enough ram to use bitmaps for those movieclips.

[Guest]

Hmm, it appears as though when I was testing my application it was being scaled down slightly in my browser. I changed the scaleMode to 'noScale' and performance improved a fair bit

[kglad]

you could try using stage3d to improve performance but there would be a lot of work to do and i suspect you're going to run out of memory.

to get a gage of what you're up against, create sprite sheets for your movieclips and see how large those bitmaps are.  if they're under 10gigs, you can use texturepacker to compress those sprite sheets and see if they can be reduced to one or two gigabytes.