More on Flex Framerate and Performance

Original link: http://www.cynergysystems.com/blogs/page/andrewtrice?entry=more_on_flex_framerate_performance

Recently my blog got added to MXNA, and it has gotten some serious hits. First of all, THANKS! I'm glad people are reading it. I'll do my best to keep it interesting and informative. Another interesting twist with more readership is that people pose questions to you, or suggest other ways of doing things. This is great feedback. Thanks to those who let me know.

Back in June, I wrote a blog posting on Flex Framerate and Performance. With all of the new readership coming from MXNA, this posting has become quite popular. I'd like to append to this topic and provide words of caution where they may be necessary, but I will reinforce that this has proven to be a powerful technique.

Originally I wrote "Increase the default framerate in your flex applications to squeeze as much performance as possible out of them". I'm not changing this opinion at all, but I'd like to add that the decision whether or not to use this technique should be determined case by case. I have used this technique to increase the quality and responsiveness of the user interface for enterprise-level Flex applications, and, in my situations, it has achieved great success. Although, this is a technique that should be used with caution. There could be possible negative side effects that should be watched out for. The decision whether or not to use this technique should be determined on a case by case basis, which ultimatley depends on how you are using flex and whether or not it helps to suit your needs. Based on my experience, it has proven very effective.

Basically, here is what I use it for:

• smoother scrolling
• smoother Drag/Drop
• smoother transitions and effects
• better overall UI performance of the applicaion

Now, lets think about the real world... It is very possible to create an application where this could cause problems. Not all developers use flex the same way, and that's where part of my advice runs into trouble.

Here's why you should use caution:

1) Distortion of embeded keyframe-based content.

Changing the framerate can cause some serious problems if you are using embded flash (swf) files that contain keyframe-based content. In the chart below, I have embeded a flash file (whose defaul framerate is 12 fps), and shown the effects of embedding that file into the flex application. You will notice that all 3 elements have different speeds, hence different framerates. The default framerate is 24 fps, and you will notice the difference between that and the swf's actual framerate of 12 fps. On my local machine, the target 99 fps actually runs at about 60 fps. I'll get more into how I calculated the fps a little later in this post (including code) and what the results mean to me. If you have a very high framerate and you do something *else* on your machine that hogs the cpu, the framerate within your flex application will drop significantly. The smooth animations you may be seeing below will slow down and/or operate at inconsistent speeds. If your keyframe based animation was designed to run at a specific fps, you probably don't want to go fooling around with it too much. Just set the application framerate to the same framerate of your keyframe-based content.

Standalone SWF FrameRate: 12 FPS	SWF Embeded Default FrameRate (24 FPS)	SWF Embeded Target 99 FPS

2) Complexity of Flex content.

In the real world, it is possible to create very "hoggy" flex applications. If you have a lot of effects, and a lot of transitions, or you have functionality that causes the entire viewport to be redrawn every frame (rather than using the cached bitmap of the objects), then the rendering of the flex application is going to require more processing power. In this scenario, setting the framerate very high could also be a bad idea. It could potentially cause a poor user experience by being a "resource hog", responding slow (or not at all), or potentially crashing the browser. Other developers have also informed me that it is possible to have process starvation, where the actionscript thread does not get executed, and result events don't fire. I have not experienced any of these scenarios, but I just want to cover all points of view here. I am aware that this was a more common problem in older versions of the flash player, but its been my experience that Flash player 9 handles this very well.

Others have pointed out that Firefox also restricts the cpu and framerate available to the flex application when it is in a non-showing tab or is not in focus. I'm aware of this, and it has been my experience that this doesn't cause any problems. Be advised, it could cause problems for you, especially if you rely on keyframe-based content. A typical flex application does not really change much when the user is not interacting with it, thus a typical flex application shouldn't be affected much... but it is still something to be aware of.

---

With that said, this is still a very powerful technique. If you want to use it, go for it, but use it wisely. Be sure to test your application on multiple systems (old & new, windows & mac, single core & dual core, etc...) and make sure it is a good experience for everyone. I have used this many times and have had great results.

Some may think a target of 99 fps is too aggressive, and I can see your point, given that the actual human eye actually percieves fluid motion at around 20-30 fps, with "true" fluid motion at around 72 fps, but this can be achieved at lower speeds, given the proper lighting conditions, brightness, contrast, and smoothness of the images (including motion blur). If you don't want to run the risk hogging too many resources, but still want better-than-average usability, set the frame rate to 50 (or any number higher than the default 24 fps). The interaction will be more fluid and will be a better experience for the user. Lets face it though, not all applications need this. If you are not using any interfaces where the increase in frame rate will be noticed, then you do not need to increase the frame rate.

The latest version of the Flash 9 player does a great job rendering swf files... With the implementation of bitmap caching and the optimizations of the Flash player 9 engine, the methods used for drawing the UI require much less overhead than in previous versions of the Flash player. It has been my experience that that framerate is an actual target. If the client machine cannot keep up, the frame rate is throttled to one that is manageable by the client system. Let's take this mini flex application for example:



The target framerate is 99 fps. The actual framerate on my machine hovers around 60 fps. Looking at the task manager, my cpu usage is zero.



Below, you'll find the code that I used to calculate the frame rate. Basically, I update a counter on every EnterFrame event. I have a timer that will reset the count every second. Pretty simple, and it does a good job.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute"
creationComplete="onCreationComplete()" frameRate="99" viewSourceURL="srcview/index.html">

<mx:Script>
<![CDATA[

private var fps : uint;
private var timer : Timer;

private function onCreationComplete() : void
{
timer = new Timer(1000);
timer.addEventListener( TimerEvent.TIMER, onTimerEvent );
timer.start();
fps = 0;
this.addEventListener(Event.ENTER_FRAME, onFrameEnter);

}

private function onFrameEnter( event : Event ) : void
{
fps++;
trace("enterframe");
}

private function onTimerEvent( event : Event ) : void
{
fpsText.text = fps.toString();
fps=0;
}

]]>
</mx:Script>
<mx:Label x="10" y="10" text="fps:"/>
<mx:TextInput x="45" y="8" width="123" id="fpsText" editable="false"/>

</mx:Application>

Now, lets take a look at the impact that 99 fps really has on my machine. I opened up 8 different flex applications in firefox, each with 99 fps. According to my fps meeter, the framerates all dropped to around 30-40fps, but the applications still ran very smoothly, and firefox was only at 24 percent cpu usage. This is a very reasonable number, given how much is actually going on within the browser. (Pentium 4, 3.2 GHz, 1.5 Gigs of RAM)





Download Source
View Source