Jump to content
Search Community

Jittery Performance - Suggestions?

ukla test
Moderator Tag

Recommended Posts

I'm in the early stages of a project - a long, horizontal landscape scene that will ultimately serve as a highly animated history time line. Before making decisions on the logic and how to build the project, I needed to do some testing in order to determine how to get the best rendering performance.

 

I figured it would be wise to see how the scene performs moving horizontally from one end to the other over the course of 10 seconds. The result is quite jittery and I'm not sure how to resolve the issue. This example uses scrollRect and I am fully aware that the landscape scene will be rendered on whole pixels. But even without scrollRect, performance doesn't change.

 

Files are attached. PLEASE DO NOT LIFT ANY OF THE GRAPHICS / TEXTURES! While only a rough concept, please show respect for creative property.

Link to comment
Share on other sites

Aha. One big problem is that you're using vectors. Those can be very processor-intensive to render. Make them bitmaps and I suspect you'll get much better performance.

 

Another technique is to use a BitmapData that's the width of the screen and then leave your graphic invisible offstage and simply copyPixels() or draw() the necessary part onto the BitmapData. Kinda like moving a camera across it, you move the rectangle that you're copying.

 

Hope that helps.

Link to comment
Share on other sites

Aha. One big problem is that you're using vectors. Those can be very processor-intensive to render. Make them bitmaps and I suspect you'll get much better performance.

 

Another technique is to use a BitmapData that's the width of the screen and then leave your graphic invisible offstage and simply copyPixels() or draw() the necessary part onto the BitmapData. Kinda like moving a camera across it, you move the rectangle that you're copying.

 

Hope that helps.

 

 

Yes, this helps. Too bad that vectors provide very manageable file size but suck when it comes to rendering.

Link to comment
Share on other sites

I'm not seeing terrible performance although I'm on a very fast computer. Are your frame rates dropping or are you just dissatisfied because the motion doesn't look smooth due to the fact that it's only rendering on whole pixel values?

 

 

Haven't been checking frame rates. But I'll get that set up.

 

Just dissatisfied with the jittery motion. Even without scrollRect setting it to whole pixels it is still jittery. I guess I expected better results than the vector version but I'm not seeing any difference.

 

I'm running 32 -bit Windows 7 on a 27" iMac > Intel Core2 Dueo 3.06 GHz, 4 GB RAM. Certainly not the fastest computer in the world, but still fast.

 

I'll keep plugging away.

Link to comment
Share on other sites

Ok, I am now thoroughly confused.

 

Just did performance tests: vector tween, vector tween using scrollrect, bitmap tween, bitmap tween using scroll rect.

 

If the code for the tests was correctly written, the vector tweens use much less memory than the bitmap tweens. Am I wrong?

Link to comment
Share on other sites

Of course. Vectors use less memory - that's why the swf files are smaller but that doesn't correlate to less load on the CPU. It can be the opposite in fact. Here's a simple example: a vector that describes a circle that's 1000x1000 pixels. In terms of memory, all it would have to do is record (in vector language) "a circle with its center at x:__, y:___ and has a radius of 500 pixels and is the color ___". That's virtually nothing. Super small. But to record that as a bitmap, it literally has to record the color/alpha/position of 1,000,000 pixels (1000x1000). That's a LOT of data. So vectors are faster to render too, right? WRONG! Remember that Flash has to ultimately render those pixels to the screen. It must determine how to render those 1,000,000 pixels anyway. So with vectors, there's an extra layer of translation. It must take the vector data in this case, figure out how/where to draw the 1000x1000 circle and then calculate each pixel in that area including anti-aliasing the edges. With the bitmap version, it has optimized algorithms that allow it to very quickly just say "oh, here's all the pixel data - throw that on the screen". In your case, you've got LOTS of vector curves, points, objects, etc. that it must calculate again and again.

 

So don't just focus on memory if you're really concerned about PERFORMANCE. Test for performance if you're worried about performance.

 

Also, in your BitmapData example(s), you set cacheAsBitmap = true on your Bitmap which is totally wasteful. That forces Flash to create another copy of the bitmap in memory AND it will only allow it to be rendered on whole pixel values - both of those hurt performance.

 

Does that help clear things up?

Link to comment
Share on other sites

I didn't mean to leave cacheAsBitmap set to true. I was working from one file and saving them out with various code changes. Overlooked that.

 

I do see higher CPU usage via my Task Manager when rendering the vector versions.

 

Thanks for the clarification.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...