mikemo

I was recently surprised to discover that setting your Flex app's frame rate to 60 frames per second instead of the default of 24 makes typing and selecting text in edit boxes noticeably smoother.

I've always noticed that when entering text into a Flash/Flex edit box, it seems just ever so slightly jittery. I don't usually notice it when typing text; but if I hold down a key to repeat it -- e.g. Shift+LeftArrow to select text, or holding down a key to repeat it -- I can see the jitter. (I have my keyboard repeat rate set to the fastest setting.) By "jitter," I mean that the onscreen display isn't quite keeping up with my typing, so sometimes it will have to "catch up" by displaying several characters at once.

This has bugged me for a long time -- after all, since Flash is good at graphics and animation, it seemed kind of lame that there was perceptible jitter when doing something as simple as typing and selecting text.

The other day, a rubber band snapped loose somewhere inside my head, and it occurred to me that perhaps, unlike native applications on most platforms, perhaps Flash edit controls are only rendered once per frame, rather than being rendered immediately in response to user actions; and that perhaps the frames per second was slow enough to be perceptible my eye. This seemed to me to be unlikely to fix the problem, because after all, the default of 24 frames per second is the same speed that movie film uses. The whole subject of the eye's perception of frames per second is actually very complicated -- this is an interesting article on the topic -- but even so, I thought 24 fps would probably be enough.

I was wrong. For each of the following samples (Flash Player 9.0 required), try selecting text with Shift+LeftArrow or Shift+RightArrow; try repeating any key such as "X"; and try typing as quickly as you can. (The difference on the keyboard-repeat tests will be much more noticeable if you set your keyboard repeat rate to the fastest setting).

Sample at 24 frames per second:

Samples at 60 frames per second:

An interactive sample that lets you try out different frame rates:

So it turns out that making text entry appear smoother is as easy as changing the frame rate of your applications to about 60 fps.

Are there any disadvantages of increasing the frame rate? The only potential disadvantage I can think of is that your program might use more CPU. But I ran some crude tests on several different machines (both Windows and Mac), and upping the frame rate from 24 fps to 60 fps had a negligible effect on CPU usage. The higher frame rate caused Flash to use about 1% more CPU during my typing tests and during some simple animation tests.

So why 60? If 60 frames per second is so great, then why not 100, or more? Well, I chose 60 somewhat arbitrarily, and all I can say is that I'm happy with 60 -- my eye sees no jitter whatsoever at that frame rate. Even though I just said that the amount of CPU usage from increasing the frame rate is negligible, there's no point in using extra CPU if it isn't making any difference. As my mother never used to say, "Use all the system resources you need, but no more."

There are also some interesting comments in the documentation for Stage.frameRate: "Note: Flash Player might not be able to follow high frame rate settings, either because the target platform is not fast enough or the player is synchronized to the vertical blank timing of the display device (usually 60 Hz on LCD devices). In some cases, a target platform might also choose to lower the maximum frame rate if it anticipates high CPU usage."

So, from now on, I plan to specify a frame rate of 60 for all of my Flex applications:

<mx:application frameRate="60">

and ActionScript applications:

[SWF(frameRate="60")]
public class MyApp extends Sprite
{
...
}

A minor tip: I suggest turning on Eclipse's "Link with Debug View" command in the Breakpoints view, and leaving it on:

This confusingly named command is actually kind of useful. The effect of this command is that every time you hit a breakpoint, the Breakpoints view will highlight the breakpoint that just got hit. This is useful after you've been debugging for a while, and your Breakpoints view has gotten cluttered with a bunch of old breakpoints that you haven't gotten around to deleting.

Of course, in a way it's pretty obvious which one you just hit -- after all, you can see which line you're on -- but still, finding it in the Breakpoints view can be tedious if there are a lot of breakpoints.

So why is it called "Link with Debug View" instead of something like "Highlight current breakpoint"? Because Eclipse allows multiple simultaneous debugging sessions, several of which could be stopped at separate breakpoints. The problem is compounded for languages like Java that support multiple threads -- several threads could be stopped at separate breakpoints. So, what the "Link with Debug View" command actually does is, each time you change the selection in the Debug view (the view with the callstack), if your new selection corresponds to a stack frame that is currently at a breakpoint, then the Breakpoints view will highlight the corresponding line.