Adobe Flash Player 9 in slow mode A script in this movie is causing Adobe Flash Player 9 to run slowly. If it continues, your computer may become unresponsive. Do you want to abort the script?
When you click no, it is freezing up because flash is taking too long to go through a chunk of code. This can happen for a number of reasons, the most commonly being an inifinite loop. The reason nothing happens when you click yes is because you have essentially told flash to stop processing the movie.
| | Solution 1: back to older version
| As it says: because newer version is not always better: http://www.oldversion.com/program.php?n=flashp
or roll back to prior sub version, as one mentioned :
so I dropped back down to version 9,0,31,0 and it worked just fine. Started quickly and played the video just fine. Went back to the beta and again it loaded the player but wouldn't start the video.
|
| Description of Macromedia Flash Player
The Macromedia Flash Player is a multimedia and application player created and distributed by Macromedia to play SWF files made using the Flash program. |
|
| | Solution 2: Upload smaller set pf pix
| | When uploading multiple files on to flickr or photobucket, sometimes your browser will become unresponsive, The issue can also arise for very large upload batches, often when people upload a large number of photos at one time. You can try uploading a smaller number of files at a time. |
| | |
|
| | Dolutions 3: Known issue for Adobe Flash, wait for newer version
| Cause for "A script in this movie is causing Flash Player to run slowly" alertIssue While viewing a Macromedia Flash movie in any Macromedia Flash Player environment (browser, standalone, or projector), an alert appears stating "A script in this movie is causing Flash Player to run slowly". Additionally, the message box gives the viewer the option to abort the script, as can be seen in Example 1. Reason Macromedia Flash Player will present this alert when a single script (for example, a one-frame ActionScript loop) continues to run for 15 seconds or longer. Giving viewers the option to end the script helps the Flash Player prevent an SWF file from freezing the viewer's browser or system indefinitely. Note: The warning dialog box has Yes and No buttons. After pressing the No button three times (approximately 15 seconds in between prompts) the data is correctly loaded and displayed. Solution The solution to this alert can vary, just as the specific cause will vary. It helps to first understand that the alert itself is not really the problem. The real problem is the performance of the application. The alert prevents the user from closing the application because they believe it is crashing. The timeout of this alert cannot be altered, however, 15 seconds is about as long as one might want to wait for an application to become responsive. The most common cause of a long delay is loading large amounts of data, or manipulating large amounts of data (specifically, string manipulation, or similar work that is typically time-intensive in client-side applications). It could also be a combination of both. Loading large amounts of data
If the application loading large amounts of data (for example, 1000 records returned from a query,) consider the delivery mechanism. Most applications cannot usefully display a set of 1000 records in one view. Instead, load and display data in small chunks. This may solve a variety of problems in the application: overall performance, usability, and as a side benefit it avoids triggering the timeout alert. Note: The number 1000 in this example is an arbitrary number. The maximum number of records allowed before this alert box appears depends on the amount of data in the XML file, the connection speed, and the speed of the client machine. Examples: - Macromedia DataGrid Component
It's difficult to work with many records at once in the DataGrid.Pull in small chunks of data, about as much as can be efficiently displayed and used at once, and you should have improved results. 100 records at once could suit the DataGrid better than 1000, for example. - Loading Large XML Files
Loading excessively large XML files can cause the script timeout error.
Time-consuming processing
The code may require more client-side processing than can be done in Macromedia Flash Player in 15 seconds on your target machine. - First, troubleshoot and locate the specific code that causes the delay. Breakpoints and trace are very useful features in isolating problem code.
- Once you locate the slow code block, consider the task it is performing. Some tasks, such as heavy string manipulation, can be time consuming. If heavy string manipulation is required, consider breaking it up into smaller tasks, or performing the task server-side.
- One way to break up a code block into smaller pieces of code is to spread the function or loop across multiple frames to 'distribute' the processing. The code may not run as quickly as a pure block of code on a fast machine, but if heavy manipulation is required, you can make your application more accessible to slow machines by considering different methods.
For example, to spread a loop out over several frames:
You might evaluate a variable in an if statement. If the variable returns 'true', have the movie break the loop by going to the next frame. If the variable does not return 'true', then have the movie loop back to the first frame (usually two to three frames back) of the movie. When you want to break the loop, set the variable to true.
Before deploying an application, test early and often in an environment matching the lower end of your target audience. You may discover performance problems, or produce the timeout alert, when machines with faster processors or connections may not have a problem. |
|
|
|
| | Solution 4: Compressing XML in transit
| http://www.actionscript.com/Article/tabid/54/ArticleID/compressing-xml-in-transit/Default.aspx
An important problem when we use XML files to load dynamic data into our Flash projects is that, as the information in those XML documents grows, its corresponding file size increases due to the growth of the inherent metadata and the nature of these plain text files. The problem is greater when our files are restricted to a fixed document format which could be more verbose than expected. This can leaves us with a set of files that are hard to manage and we must distribute in the network. A collateral problem of handling large XML documents in previous versions of the Flash Player (and fixed in the currently 7 series) is that you could trigger a Flash warning message (you know, the one that says "A script in this movie is causing Flash Player to run slowly...") when we are dealing with huge files. You can see more on this issue in Bill Drol's web site http://www.billdrol.com/Extras/extra27.html and http://www.billdrol.com/Extras/extra28.html.The solution to huge files and their distribution over the network rely upon compression as a method to keep the information safe, but reducing the size of the original file. This helps saving bandwith (which is always desired), but ensures that data is provided as you would expect. Later you must decompress the file in your Flash document to parse the XML in the same way you used to do.You can find a complete solution to this issue on http://www.strille.net/. He creates a small program called http://www.strille.net/tutorials/FlashXMLCompressor/index.php that runs on the .NET framework and uses the lossless algorithm LZ77 to accomplish the task to compress the XML files. Later, you'll decompress the affected files inside Flash at runtime supported by a little XML prototype placed in the Flash document to reverse the process.I could test this technique with a http://www.musicxml.org/xml/mut.html that represents the music piece "Mut" from Franz Schubert's Winterreise, D. 911 in XML format. This type of files has the fame of being very large and verbose. As you can see, the example file is 225kb (notice the zip version size is only 9kb), in my opinion, a considerable size to work with on the internet, but after file compression with the Flash XML Compressor tool, it's reduced to 16kb!!! wow!. This is a ridiculous size for a file being shared over the wire. Once the file has reached the Flash client in record time (hopefully!) the following strille prototype enters the scene to decompress:XML.prototype.parseXMLStandard = XML.prototype.parseXML;XML.prototype.parseXML = function(i) { if (i.charAt(0) != '<') { var ecPos = i.indexOf(" ")+1; var eC = i.charAt(ecPos); i = i.substr(ecPos+1); var o = ""; var iL = i.length; for (var n=0;nWith this method you can still load traditional XML files as well as LZ77 compressed XML files so your Flash doesn't loose flexibility. In addition, this is a very fast decoding snippet, not as the LZ77 compression algorithm that is CPU intensive, but we mainly need speed at runtime so this method could be as transparent as possible to the end user.The author of Flash XML Compressor guarantees a reduction of about 30 to 50 percent in file size using this approach, reaching in some cases up to 90 percent, without loss of information. This could means to XML what mp3 was to music, but without information loss.Now you can play with all those heavy XML files without generating too much network traffic, and your users would be grateful because you're saving them time. Happy compression."> |
| | |
| |
