Flash problems, seeking expert answers please

Question

File in question: Gisser Automotive - Rare Growth Stock Opportunity
1) Here is the basic code for the preloaded I use:
stop();
this.addEventListener(Event.ENTER_FRAME, loading);
function loading(e:Event):void{
var total:Number = this.stage.loaderInfo.bytesTotal;
var loaded:Number = this.stage.loaderInfo.bytesLoaded;
loadingbar3.scaleX = loaded/total;
loadText.text = Math.floor((loaded/total)*100)+ "%";
if (total == loaded){
play();
this.removeEventListener(Event.ENTER_FRAME, loading);
2) I create motion through Classic Tweens
3)  Any suggestions so slower machines don't experience jerky motion?
4) What method in Photoshop will "optimize" the images? And do I need to worry now after the Flash is completed, if the swf file is 4 MB or less?
5) Images are mostly PNG 24. What step(s) would you take using Photoshop to optimize this file type?
6) If in Flash Publish settings, I adjust image quality, say down to 80% or so, won't this override any image settings or optimization made in Photoshop?
7) My client asked if there is another export file format besides .swf, and also if this alternative format will retain interactivity and remove any glitches in motion.
8) Please inform me if you see this jittery animation, and also, exactly what your PC configuration/RAM/OS/browser is.
In summary. we are trying to eliminate jerky motion, making it run smooth, and reduce file size so slower PCs view this Flash without jittery animaiton.
Thank you.

Answer 1

there are a myriad of things that can be done without decreasing quality.  below  are two pages from a 65 page chapter (optimizing game performance) in a book i worte (Flash Game Development: In a Social, Mobile and 3D World)
here's some info about cacheAsBitmap, Flash CS4 Professional ActionScript 2.0
Unfortunately, I know of no completely satisfactory way to organize this information. In what follows, I discuss memory management first with sub-topics listed in alphabetical order. Then I discuss CPU/GPU management with sub-topics listed in alphabetical order.
That may seem logical but there are, at least, two problems with that organization.
I do not believe it is the most helpful way to organize this information.
Memory management affects CPU/GPU usage, so everything in the Memory Management section could also be listed in the CPU/GPU section.
Anyway, I am going to also list the information two other ways, from easiest to hardest to implement and from greatest to least benefit.
Both of those later listings are subjective and are dependent on developer experience and capabilities, as well as, the test situation and test environment. I very much doubt there would be a consensus on ordering of these lists.  Nevertheless, I think they still are worthwhile.
Easiest to Hardest to Implement
Do not use Filters.
Always use reverse for-loops and avoid do-loops and avoid while-loops.
Explicitly stop Timers to ready them for gc (garbage collection).
Use weak event listeners and remove listeners.
Strictly type variables whenever possible.
Explicitly disable mouse interactivity when mouse interactivity not needed.
Replace dispatchEvents with callback functions whenever possible.
Stop Sounds to enable Sounds and SoundChannels to be gc'd.
Use the most basic DisplayObject needed.
Always use cacheAsBitmap and cacheAsBitmapMatrix with air apps (i.e., mobile devices).
Reuse Objects whenever possible.
Event.ENTER_FRAME loops: Use different listeners and different listener functions applied to as few DisplayObjects as possible.
Pool Objects instead of creating and gc'ing Objects.
Use partial blitting.
Use stage blitting.
Use Stage3D.
Greatest to Least Benefit
Use stage blitting (if there is enough system memory).
Use Stage3D.
Use partial blitting.
Use cacheAsBitmap and cacheAsBitmapMatrix with mobile devices.
Explicitly disable mouse interactivity when mouse interactivity not needed.
Do not use Filters.
Use the most basic DisplayObject needed.
Reuse Objects whenever possible.
Event.ENTER_FRAME loops: Use different listeners and different listener functions applied to as few DisplayObjects as possible.
Use reverse for-loops and avoid do-loops and while-loops.
Pool Objects instead of creating and gc'ing Objects.
Strictly type variables whenever possible.
Use weak event listeners and remove listeners.
Replace dispatchEvents with callback functions whenever possible.
Explicitly stop Timers to ready for gc.
  16. Stop Sounds to enable Sounds and SoundChannels to be gc'd