8.3. Updates and Frame Rates

onMouseMove> ball_1_mc_y: 239.95
onMouseMove> ball_1_mc_x: 138
onMouseMove> ball_1_mc_y: 245.95
onMouseMove> ball_1_mc_x: 144
onMouseMove> ball_1_mc_y: 246.95
onMouseMove> ball_1_mc_x: 147
onSync> ball_1_mc_y: 246.95
onSync> ball_1_mc_x: 147
onMouseMove> ball_1_mc_y: 243.95
onMouseMove> ball_1_mc_x: 149
onMouseMove> ball_1_mc_y: 229.95
onMouseMove> ball_1_mc_x: 149
onMouseMove> ball_1_mc_y: 216
onMouseMove> ball_1_mc_x: 148
onMouseMove> ball_1_mc_y: 211
onMouseMove> ball_1_mc_x: 143
onSync> ball_1_mc_y: 211
onSync> ball_1_mc_x: 143

There are more mouseMove events than synchronization events. So, although the shared object's data is updated each time onMouseMove( ) is called, not every update is sent to the server and synchronized.

Shared objects post updates at regular intervals. At the end of each time interval, if any changes have occurred in the properties of the data object, the changed properties and their values are sent in one batch to the server. If no changes have occurred since the last batch of updates were sent, no update occurs.

With rapidly changing data, sending all the updates to the server could generate more network traffic than is really needed. The shared ball is a simple example. Other examples are shared cursors, avatar positions, game element positioning, and scrolling or highlighting text in a shared text field.

Of course, some situations require that a sequence of messages be sent to FlashCom without loss of any in-between values. In those cases, remote method invocation can be used. You can use the send( ) method of a SharedObject or NetStream object or the call( ) method of a NetConnection or Client object. Remote method invocations are reliably sent to and queued on the server; they are covered in more detail in Chapter 9.

By default, shared objects post updates to the server at a regular interval equal to the movie's frame rate, which may be slower or faster than desirable. The SharedObject.setFps( ) method changes the update rate for shared object data. For example, inserting the following statement in the onConnect( ) method of Example 8-4 sets the number of updates to three per second, regardless of the movie's frame rate:

so.setFps(3);

Just as Flash frame rendering can slow down during demanding operations, under heavy network load or over a slow connection, the rate of shared object updates may also slow down. When the shared object update rate slows down, only the most recent data values are sent. Any in-between values from a dropped frame are discarded. Before a new update is sent, the shared object always waits for the results of any outstanding updates. In other words, before the shared object sends an update request to the server, it waits until the server responds to the previous update request. The server may accept the changes or reject them. Until the shared object receives notification of what has happened, it does not send any new (pending) updates.

Why not just set a high frame rate, such as 24 fps, and let the movie and server handle it as described? In some applications, such as games, you may want to. But you may also be creating more network traffic than necessary and therefore consuming bandwidth better spent on sound or video.

Also, consider what happens if a movie is running at 24 fps but it takes 100 milliseconds (one-tenth of a second) for a message to get from the movie to FlashCom and return: FlashCom cannot achieve more than a 10 fps shared object update interval for a client with a 100 ms round-trip time. It also takes time for the server to process update requests. By attempting to send messages 2.5 times faster than they can be processed over the connection, you waste bandwidth; the server will discard updates for clients with higher network latency, resulting in different update rates for different clients. A more realistic approach is to set the update rate 30 to 50 percent slower than the average latency. For example, if you have an average 100 ms latency (10 fps), use an update rate of 5 to 7 fps.

If you set the shared object update rate to 0, the shared object will stop sending updates to the server entirely. Stopping updates temporarily is a good idea when you have a large number of updates that you would like to send in one batch. For example:

// Stop all updates.
so.setFps(0);
// Change all the properties in one batch.
for (var p in streamInfo) {
   so.data[p] = streamInfo[p];
}
// Restart updates.
so.setFps(7);

A modified version of Example 8-4 on the book's web site allows you to adjust the update rate while moving the shared ball to see how it affects the appearance of motion.