Circumstances in the form of an upcoming possible biopsy Tuesday requires preparation for a more rapid transition to the newer format. Nothing really serious expected, been through this kind of thing before, changes your thinking for a while at least. The following ideas have been edited down a bit:
Adaptation to economical mobile devices suitable for student use requires considerable simplification. The current concern is ""Smartbooks" OLPC//News
Apparently, some part of both home and school work will use batteries and relatively weaker processors.
For myself, I am guessing: Canvas and/or html5 vector graphic gui in 2-3 years. Today, Flash is the only way for me (and most teachers) to develop complex animation content for general use. By October 2010 we may have some idea how Flash 10.1, now officially released actually works on mobile devices as well as the education capabilities of the Ipad and PC Tablet formats. Content distribution is the goal, I would like to be ready to use whatever tools the winds blow my way.
My own programming is certainly inadequate but some work on the imagery used here should be helpful. I'm generally using Adobe guidlines for optimization summarized below.
Finished reading a PDF "Optimizing Performance for the ADOBE FLASH PLATFORM". It is for Flash Developers but I can follow some of it for background and there are useful phrases such as:
"Consider whether your desired level of richness is a good match for the performance characteristics of the machines and devices on which your application runs."
____________________
Some issues
Motion Transparencies, Transitions
Euclidean Algorithm 2
Number Line
Ratios 3 p 2,6 Mesolabium (?)
Nested Intervals p5 (ghost)
Dienes Multiplication p1.2,.3,.4 (alpha only)
Dienes Blocks 2 p4
Integration 1
p3 (transparency zoom in)
p17 figures fade in/out
p19 Riemann rectangles (alpha but stationary)
p20 stationary rectangles under curve - alpha
Integration 2
p1 alpha - left side
p8 numbers fade out
FOIL - highlighted by transparencies
Integration 3 - some transparencies, mostly stationary
Irrationals p2
Mesolabium Linkage p 3 (animated alpha)
___________________
Gradient
Sum of First n Squares p5, radial gradients
___________________
Continuous Motion
Calculus (see Dienes Blocks 2)
Phonograph p3
Motion Circular 6
_____________________
Display Objects
(ror - At some point, but making everything into a movie clip is helpful right now in reducing clutter and duplications that have been accumulating.
Even the date is now an MC. Convenient though wasteful of memory. In time.)
http://www.adobe.com/devnet/flash/articles/flash8_bestpractices_11.html#optimizing_graphics
Flash 8 Best Practices
Optimizing Graphics and Animation
Avoid gradients...
Alpha or transparency...to a minimum.
Animating transparent graphics over bitmaps is a particularly processor-intensive kind of animation, and must be kept to a minimum or avoided completely.
The best bitmap format to import into Flash is PNG, they have RGB and alpha information for each pixel...you retain some ability to edit the graphic objects in the FLA file.
Optimize bitmaps
Vector graphic...is preferable in most cases... reduces file size, because the images are made from calculations instead of many pixels. (ror - issue of calculations vs bitmap rendering on mobile devices?)
Limit colors.
Avoid scaling bitmaps.
Set the _visible property to false instead of changing the _alpha level to 0 or 1.
Calculating the _alpha level for an instance on the Stage is processor-intensive. If you disable the instance's visibility, it saves CPU cycles and memory, which can give your SWF files smoother animations.
Instead of unloading and possibly reloading assets, set the _visible property to false, which is much less processor-intensive.
***
Reduce the number of lines and points.
Use the Optimize Curves dialog box (Modify > Shape > Optimize) Use Multiple Passes option.
Try different ways of producing an effect, and test.
Find the lowest frame rate possible. For detailed information, see "Animation Frame Rate and Performance".
***
Animation Frame Rate and Performance
Setting a frame rate too high can lead to processor problems, especially when you use many assets or use ActionScript to create animation.
***
onEnterFrame
Note: When you use an onEnterFrame event handler to create scripted animations, the animation runs at the document's frame rate, similar to if you created a motion tween on a timeline.
***
setInterval Function
An alternative to the onEnterFrame event handler is setInterval.
Instead of depending on frame rate, you call functions at a specified interval.
Like onEnterFrame, the more frequently you use setInterval to call a function, the more resource intensive the animation is on your processor.
***
Also, especially if you're working with timeline-based animation, select a frame rate for your animation as early as possible in the development process.
When you test the SWF file, check the duration, and the SWF file size, of your animation. The frame rate greatly affects the speed of the animation.
***
Filters and SWF File Performance
(ror - I haven't used filters to date but it may be that mobile devices require more bitmaps and will keep some of this in mind)
Avoid using an excessive number of filters, and use a lower quality setting when possible.
Caution: If a 100 pixel x 100 pixel object is zoomed in once, it uses four times the memory since the content's dimensions are now 200 pixels x 200 pixels. If you zoom another two times, the shape is drawn as an 800 pixel x 800 pixel object which uses 64 times the memory as the original 100 pixel x 100 pixel object.
Whenever you use filters in a SWF file, it is always a good idea to disable the zoom menu options from the SWF file's context menu.
***
Bitmap Caching and SWF File Performance
(ror - this may be worthwhile)
Flash Player 8 introduces bitmap caching, which helps you enhance the performance of nonchanging movie clips in your applications.
When you set the MovieClip.cacheAsBitmap or Button.cacheAsBitmap property to true, Flash Player caches an internal bitmap representation of the movie clip or button instance.
This can improve performance for movie clips that contain complex vector content. All of the vector data for a movie clip that has a cached bitmap is drawn to the bitmap, instead of to the main Stage.
Note: The bitmap is copied to the main Stage as unstretched, unrotated pixels snapped to the nearest pixel boundaries. Pixels are mapped one-to-one with the parent object. If the bounds of the bitmap change, the bitmap is re-created instead of being stretched.
It's ideal to use the cacheAsBitmap property with movie clips that have mostly static content and that do not scale and rotate frequently. With such movie clips, using the cacheAsBitmap property can lead to performance improvements when the movie clip is translated (when its x and y position is changed).
Enabling caching for a movie clip creates a surface, which has several advantages, such as helping complex vector animations to render fast.
...Overall performance of cached data depends on how complex the vector data of your instances are, how much of the data you change, and whether or not you set the opaqueBackground property.
If you are changing small regions, the difference between using a surface and using vector data could be negligible. You might want to test both scenarios with your work before you deploy the application.
**
When to Use Bitmap Caching
Complex background image:
An application that contains a detailed and complex background image of vector data (perhaps an image where you applied the trace bitmap command, or artwork that you created in Adobe Illustrator).
Scrolling text field:
Windowing system: An application with a complex system of overlapping windows. Each window can be open or closed (for example, web browser windows). If you mark each window as a surface (set the cacheAsBitmap property to true), each window is isolated and cached. Users can drag the windows so that they overlap each other, and each window doesn't need to regenerate the vector content.
**
When to Avoid Using Bitmap Caching
Misusing this feature could negatively affect your SWF file. When you develop a FLA file that uses surfaces, remember the following guidelines:
Do not overuse surfaces (movie clips with caching enabled). Each surface uses more memory than a regular movie clip, which means that you should only enable surfaces when you need to improve rendering performance.
Do not overuse bitmap caching. A cached bitmap can use significantly more memory than a regular movie clip instance... it might use 250K instead of 1K.
Avoid zooming into cached surfaces.
Use surfaces for movie clip instances that are largely static (nonanimating). You can drag or move the instance, but the contents of the instance should not animate or change a lot.
For example, if you rotate or transform an instance, the instance changes between the surface and vector data, which is difficult to process and negatively affects your SWF file.
Avoid mixing surfaces with vector data.
***
Working with Components in Flash Player
(ror - I avoided entirely so far, skip this section)
The component framework enables you to add functionality to components, but it can potentially add considerable file size to an application.
***
Where to Go from HereChanging your workflow to incorporate best practices (or standardizing your code) can take time and patience. However, you will quickly realize the benefits to your code and workflow.
If you're just starting to learn Flash, use and refer to this guide frequently to help you form good habits as you learn. If you do this, you can avoid having to retrain yourself later on.
_________
(mobile)
http://www.tipsblogger.com/2010/03/10-tips-to-optimise-your-site-for.html
Avoid Flash
(unworkable for the moment - some of this may be changing with Flash Player 10.1 but will keep in mind the difference between phone and smartbook.)
Keep it Slim, designing your site in one central column, to keep things central for mobile users.
Make Navigation Really Simple
Mobile users will struggle to navigate your site if your navigation relies on clicking images, as these will take longer to load on slower connections. So, design the navigation and user journey depending as little as possible on images and plugins to make things smoother on mobiles.
Optimise HTML
Use the most efficient, semantic HTML you can, and put more emphasis on presentation in your CSS. CSS is more powerful and doesn’t clutter your site with presentational data, so the site can be viewed by mobile users more easily.
Lose the Special Effects
Dynamic effects simply don’t translate to most mobile browsers well. They do not add much to a site when viewed on a PC, and bring nothing but annoyance when users try to view your site on a mobile.
Control Text Sizes
Large text is unwieldy on a mobile device as the screen is so much smaller, and users have to scroll down through squashed-up words to get to body text. With this in mind, your large text headers should be no more than twice the size of your body text, and headlines should be as short as possible to avoid them spilling over into several lines on a mobile device.
Write for Mobile Users
The majority of mobile browser users, according to mobile operator Orange, feel that there should be specific content for mobile rather than the same content as on web pages.
If you’re planning to go down this route, remember that you shouldn’t just change the structure and features of your mobile content; you need to edit the actual words as well. Mobile users are more likely to be on the go when they access your site, and so have less time to read, and there’s also the problem of a lack of space.
So, your copy for mobile should be as concise and punchy as possible.
___________
http://www.adobe.com/devnet/devices/articles/ota_delivery_04.html
Optimizing your content for OTA delivery (over the air)
In order to optimize graphics, you need a graphics authoring tool like Adobe Photoshop or Macromedia Fireworks as well as some understanding about file formats and their good and bad features.
Sometimes it's a good idea to use vectors instead of bitmaps, because vectors are mathematical functions, not concrete pixel-by-pixel graphics like bitmaps. Just remember to check that the vectors don't tax the device too much, and that the application runs smoothly on the device.
PNG is a format that uses both bitmap and vector graphics, and is often the best choice with Flash Lite.
It is somewhat dependent on the file format, but when optimizing, you have control over the number of colors (color depth), compression strength, and image resolution (see Figure 1): 72 dpi for mobile devices and computer screens, around 120–150 for newspaper quality, and 300 dpi for print quality, etc.
Hard-coding
Always code in a portable way. If you draw graphics by using code, hard-coding something is a bad idea because it is always device-specific.
(ror-haven't done any of this - skip for now...may be relevant to "Canvas" in the future)
Contrast
All mobile devices differ from one other, and screen contrast and brightness vary wildly. Due to these differences, the way colors are perceived by the user differ as well...and always test on the target devices in broad daylight.
And yes, it's a must to test on every target device in order to spot the anomalies. It's no use if your applications look good on your own mobile device with your profile but bad on every other device. What does this have to do with OTA delivery? If the end users don't like what they see, the impact on you and your business will be inevitably bad.
Tip: Avoid using many overlapping transparent PNG layers, as the graphics may start to flicker.
**************
**************
**************
THE BIG ISSUE
Animation
The basic thing to keep in mind when creating animations is that mobile devices are not desktop computers or consoles. Using many complex animations can easily bring a mobile device to its knees.
When making animations, or making single images called sprites that form the animation, always look for a solution that has the fewest frames possible—meaning fewer kilobytes and/or less taxation on the mobile device's CPU.
We recommend that you use tween animations (motion and shape) to save time and kilobytes. The most efficient way to make animations is coding them using ActionScript. The combination of these two techniques is by far the best solution when applicable.
For more information on bitmaps vs. vectors, check out this Flash Lite article on LiveDocs: Bitmap versus Vector Graphics.
Figure 2. Effect of gradients and alpha transparency on file size in bitmap and vector sprites
Tip: There is at least one graphics handling bug that can affect optimization possibilities. Flipping transparent PNG images doesn't work correctly on all devices (at least on the Flash Lite 2.0 player's developer version). Flipping transparent PNGs doubles an animation's size because you're not able to use the same image for both orientations (like animation to left and right).
Video
Video editing should be done in a video editing program like Adobe Premiere. The Flash Lite 2.x player can play any video format supported by the target device. Because the device itself decodes and renders (and even streams) the video, we can't provide a general guideline for which video format to use. Check with the manufacturer or use ActionScript in your application to find out which, if any, video formats are supported and then serve the right one accordingly.
Tip: Videos tend to involve large file sizes.
_____________
http://livedocs.adobe.com/flashlite/2/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000086.html
Flash Lite 2
Developing Flash Lite 2.x Applications > Optimizing Content for Performance and Memory > Performance optimization > Bitmap versus vector graphics
Bitmap versus vector graphics
Flash Lite can render both vector and bitmap graphics, and each type of graphic has its advantages and disadvantages. Whether to use vector or bitmap graphics is not always a clear decision, and often depends on several factors. This section discusses some of the differences between vector and bitmap graphics to consider when deciding what type of graphic to use.
Vector graphics are compactly described in SWF files as mathematical equations, and then rendered at runtime by the Flash Lite player. In contrast, bitmap graphics are represented as arrays of picture elements (pixels), which require more bytes of data to describe. Therefore, using vector graphics in your application can help keep file size and application memory usage down.
Vector graphics also maintain their smooth shapes when scaled in size, unlike bitmaps images that can appear boxy, or pixelated, when scaled.
Compared to bitmaps, however, vector graphics require more processing power to render, especially vector graphics that consist of many complex shapes and fills.
Consequently, heavy use of vector shapes can sometimes reduce overall application performance.
Because bitmap graphics don't require as much processing time to render as vectors, they can be a better choice for some applications.
For example, a road map of a large city would have too many complex shapes to scroll and animate well on a mobile phone if it were created as a vector graphic; a bitmap would animate better.
Following is a list of additional considerations for using bitmap and vector graphics in your Flash Lite application:
Whenever possible, do not use strokes on your vector shapes, because doing so increases the number of rendered lines.
As a general rule, use bitmaps for small, complex images (such as icons) and vector graphics for larger and simpler ones.
Import bitmap graphics at the size that they will be used in the application; don't import large graphics and scale them down in Flash, as this wastes file size and runtime memory.