Combining Bitmaps and Vector Art

Whenever you plan to use bitmaps and vectors together in Flash, you need to be aware of a few issues. Combining bitmaps and vectors almost always has an impact on file size, but increased file size isn't the only issue you have to deal with. Whenever a Flash movie plays, it's using the computer it's playing on to run the calculations necessary to render the vector art. Let me tell you, having some types of vector art animating over the top of a bitmap can turn your file into a real resource hog. If you're depending on other people's computers to do some work, the question becomes how much work are you expecting them to do? You won't make any friends by crashing their computers and consuming all their system resources!

To understand the issues involved in combining bitmaps and vectors, take a look at an example of how not to do it. Why start from there? Because if you know how to spot the problems, it'll make it easier to avoid making them as you start to build your own files.

Bitmap/Vector Combinations Gone Bad

Sometimes, the best-laid plans go astray. That's what happened with the next file at which you'll be looking. Open FigSubCulture.swf in the Chapter_05/Assets folder.

This file originally was created as a background screen, something that would be left open and running on the desktop as a backdrop for presentations. It doesn't have to actually do anything other than sit there and look pretty. It does that part fairly well, so what's the problem? The problem is performance.

You might find that when you create a Flash file, your primary concern is with keeping the file size within certain limits. After all, file size dictates download time. That was the case with this project. The final size of the Flash Player movie was about 60KB, which is acceptable, especially for a file that was intended for internal use. However, there are other issues you have to take into consideration besides the file size.

The problem with this file is that when we left it open and running in the background at Fig Leaf, we noticed some significant system performance problems. After a little checking around, we discovered that the file, even when idle, was causing the CPU usage to average about 75 percent, with frequent peaks to 100 percent. That is not a good thing.

So what is it in this file that is causing such a huge performance hit? It's not any individual element of the file that is causing the problem, but a combination of several elements.

Think about the operations in Flash that are processor intensive . The big CPU killers are the following:

• Shape tweening

• Multiple tweens in the same frame

• Alpha animations

• Masking

• Gradients

• Any of the preceding items over a bitmap

This file has them all.

So, how do you avoid making this mistake? How do you tell when you have too much of a good thing? You can tell by monitoring the effect of your SWF file on your CPU usage as you build the file.

Monitoring Your CPU Usage

Monitoring your CPU usage is easy if you are running Windows NT or Windows 2000. (Note to Macintosh users: I haven't been able to find an equivalent utility for the Macintosh. You'll have to pester your Windows friends.) Just open up the Task Manager (see Figure 5.10) by right-clicking the task bar and choosing Task Manager or by pressing Ctrl+Alt+Delete and selecting Task Manager from the pop-up window. To see overall system performance as a graph, select the Performance tab. If you want to watch just the Flash Player performance, choose the Processes tab and look for FlashPla.exe.

Figure 5.10. On the Windows NT or 2000 platforms, you can use the Task Manager to monitor the effect of your SWF file on the CPU usage.

Tip

I use a third-party tool, TaskInfo2000 by Iarsn, to monitor my CPU usage because it also gives me a long-time average of the CPU usage. I find that that gives me a better feel for the performance of my file. TaskInfo2000 is available for Windows 95/98/ME/NT/2000 and can be found at http://www.iarsn.com/index.html.

When you are monitoring the CPU usage for a movie, you need to make sure you are monitoring the usage outside the Flash authoring environment. If you use just Test > Movie, you get an incorrect reading because of the internal Flash processes that are taking place. You always want to launch the actual SWF file outside of Flash.

Obviously, different computers are going to vary in processor speed. However, you should be able to get a good feel for what is acceptable and what is not. A spike in CPU usage at the beginning of a file ”while it's still loading ”is okay, but only if it immediately drops down to 30 percent or lower. It's always a good idea to test on as many different types of machines as is feasible .

Can This File Be Saved?

How drastically would you have to alter the construction of this file to make it perform better? That's worth taking a look at.

On the CD in the Chapter_05/Assets folder, there are a series of FLA files (subculture_build and subculture_build_a through subculture_build_f) that reconstruct this file, layer by layer. By building the file in this fashion, you can begin to find and tweak the problem areas as you go. In all cases in the following sections of this chapter, the SWF was tested at the size at which it was built (800 x 400). If you increase the SWF to full screen, it consumes more resources. I'm showing you the results I got on my computer; your mileage might vary, but this should give you a good base from which to work:

File:  subculture_build.fla
Content:  Background  bitmap
File (SWF) size:  59KB
CPU usage:  Minimal,  drops  to  0  almost  immediately
Change:  In  Publish  Settings,  change  the  JPEG  compression  from  80  percent  to  30  percent
New (SWF) size:  23KB
New CPU usage:  No  change

File:  subculture_build_a.fla
Added content:  BlueGreenGlow
File (SWF) size:  26KB
CPU usage:  Spikes  to  6  percent,  averages  4  percent
Change:  No  changes
New (SWF) size:  26KB
New CPU usage:  No  change

File:  subculture_build_b.fla
Added content:  Animated  logo,  with  mask  and  alpha
File (SWF) size:  28KB
CPU usage:  Spikes  to  48  percent,  averages  22  percent
Change:  Remove  all  unnecessary  content,  trim  logo  vector  to  size  of  mask,  remove  masking  layer
New (SWF) size:  27KB  (subculture_build_c.fla)
New CPU usage:  Spikes  to  20  percent,  averages  11  percent

File:  subculture_build_d.fla
Added content:  Black  gradient  fade  over  logo  tween
File (SWF) size:  27KB
CPU usage:  Spikes  to  35  percent,  averages  15  percent
Change:  Trim  unnecessary  part  of  gradient  fade
New (SWF) size:  27KB
New CPU usage:  Spikes  to  30  percent,  averages  13  percent

File:  subculture_build_e.fla
Added content:  Horizontal  and  vertical  tweening  lines
File (SWF) size:  29KB
CPU usage:  Spikes  to  35  percent,  averages  21  percent
Change:  Trim  unnecessary   parts  of  horizontal  and  vertical  lines
New (SWF) size:  27KB
New CPU usage:  Spikes  to  30  percent,  averages  19  percent

File:  subculture_build_e.fla
Added content:  Animation  of  Fig  Leaf   name
File (SWF) size:  32KB
CPU usage:  Spikes  to  40  percent,  averages  24  percent
Change:  No  additional  changes
New (SWF) size:  32KB
New CPU usage:  Spikes  to  40  percent,  averages  24  percent

Original file:  subculture.fla
File (SWF) size:  59KB
CPU usage:  Spikes  to  100  percent,  averages  75

Tip

You might notice a slight and unexpected shift in your bitmap image when you have an Alpha tween over a bitmap. Before you panic, make sure you test it using the player (use F12 to launch it in a browser). If it still happens, there are several potential fixes:

• If your Alpha tween is set at 100 percent or 0 percent at any point, try changing the setting to 99 percent or 1 percent.

• You also can try resizing your bitmap slightly or setting the Alpha of your bitmap to 99 percent.

• Make sure your bitmaps are aligned exactly on a pixel, not on a subpixel. Use your Align tool to align the bitmap to the top left corner of the Stage.

• Open the Bitmap Properties dialog box in the Library and deselect Allow Smoothing.

By making just a few changes, you were able to dramatically improve the performance of this file. Keep that in mind as you build your own files. Remember: Test early, test often!

Not only can you monitor your CPU usage to isolate problem areas, you also can use the Bandwidth Profiler, which you looked at briefly earlier in this chapter, to check for potential playback problems.