Aptana Cloud is a scalable Elastic Application Cloud™ featuring the most popular and widely adopted Web infrastructure, ready to use and ready to scale as you need it. Aptana Cloud also plugs right into your IDE to provide instant deployment, smart synchronization, and seamless migration as you scale. Aptana Cloud is ideal for developers who use scripting languages to create Ajax, Facebook, mySpace and all other sorts of Web applications.

Tomorrow afternoon I am going to be having a chat with a few of the guys from SlideRocket. If you aren't familiar with it - SlideRocket is a Flash/Flex based RIA that really does online presentation creation and delivery right. They are currently in private beta. Let me know if there are any questions that you would like me to ask.

SlideRocket Screenshot

SlideRocket Information

SlideRocket Blog
TechCrunch Article
Scoble on SlideRocket

In the last tutorial, I examined some additional techniques for querying an existing database. Today I want to explain how you create a database and create a table inside of that database.. If you are good with SQL and have followed along with this series, this concept will work as expected.

Creating Databases

I briefly touch on creating databases in a previous tutorial. The concept is very similar to working with a pre-populated database. Just as with a pre-populated database you will need to create an instance of the File class that points to a file. If that file does not exist, then the database will be created when the open or openAsync methods are called.

If you do not pass an instance of the File class to the open or openAsync methods, a database is created in memory, and it will remain as long as the application is open.

Affinity Types

Before you can create any tables, you will have to know about affinity types (data types) within SQLite. AIR contains ten different affinity types that can be used:

• TEXT (also called STRING)
• NUMERIC
• INTEGER:
• REAL (also called NUMBER)
• BOOLEAN
• DATE
• XML
• XMLLIST
• OBJECT
• NONE

NOTE: Each affinity can handle data differently. You will want to consult the information on Affinity Types in the documentation before you design your database schema.

Creating Tables

To create tables within AIR, you simply need to execute an SQLStatement just as you did to query the data. For example, let's say that you wanted to create a table names 'Contacts' with the following fields:

1. firstName: This will just be a string
2. lastName: This will just be a string
3. age: This will be a uint
4. gender: This will be a Boolean value

The table is created in the example below:

The actual SQL statement is found inside of the createTable method. There are a few things that could have been added to this table (such as an auto-incrementing ID field), but hopefully now you feel comfortable creating tables with the embedded SQLite database in AIR.

Deleting Tables

If you are in a situation where you need to delete a table, you will need to execute the following SQLStatement:

If you omit the 'IF EXISTS' portion of the query, and the table does not exists (for example, if it was already deleted) the query response will be an error.

Resources

Column Affinity Descriptions

Unfortunately, when I looked into the details, there wasn’t much to see. The claim was that the FLV/SWF/F4V binary formats will be Open, and there will no longer be the restriction that said you can’t RUN the code. The problem was that there was no license to go along with this claim, which means that we can’t actually do much with it yet. Adobe isn’t more “Open” today than it was the day before the announcement. This will hopefully change very soon when we actually see the license, and hopefully see even more.

There are also two models, BookieModel and AdminModel. Models are just buckets for data. Models may become more complex and expose a set of methods as an API to act on the data they hold. Figure 20 shows the two models in Bookie.

The role of a model in a Cairngorm application is to hold data that drives the view. The controllers of the application, which are commands accessed through a FrontController, do what they need to do to get data in a form ready for the model, which may include accessing a service, then change the data on the model. The view is generally "bound" to the model's data and updates automatically through Flex's excellent binding mechanism. Again, we'll see how the view works in the next iteration.

Figure 20. The two models in Bookie

Models are generally simple beasts. Let's look at the BookieModel:

This model implements ModelLocator, which is simply a marker interface, meaning that it doesn't specify any methods to implement; it just marks the class as being of a certain type. Notice that the class is annotated with the [Bindable] metadata tag, just like our ActionScript DTOs. This means any public properties on the model are available for use in Flex's binding framework.

Under the "States" comment are three constants which hold unique strings that we'll use to control the state of the Application view, index.mxml. At any point, currentState can be set to any one of these constants' values, and later we'll see how the application uses those constants to define states.

Get your copy of Tony Hillerson's Enterprise Application Development with Flex.

Next are all the public properties that will drive the view. We'll keep a list of all the books, authors, subjects, and books to reserve on the model, as well as a reference to the person logged in. The loginFailedMessage is there to be bound to the view and set with a command in case the login process fails.

That first private variable is a static instance of a BookieModel, which should tip you off that we're going to use the singleton pattern here. Models need to be singletons, so we need to make sure there's only one instance of the object in the application. This is important, because the model represents the state of the client, and that can't be done well if there isn't a definitive, single version of that state. Here are the rest of the methods necessary to implement the singleton pattern:

First there's a static accessor method that returns the single instance, and creates it if it's not already there. Now, in Java or other languages where you can make a constructor private, you'd do that to complete the singleton pattern, to make sure that only the class could instantiate an instance of itself. ActionScript doesn't allow private constructors, so we instead use a little hack. Inside the class, at the bottom after the end of the package block, we define another class called ModelInitializer, which is visible only to the model class because it's outside the package, but in the same file. That way, we can make sure, again, that only the model class can instantiate itself.

Next there are a few helper methods: one to initialize the model, which means to clear out any data that it was holding, and another to calculate a date two weeks in the future to use as a "reserved until" date for when we make reservations.

Next time we're going to see how we can unit test Flex with Flex Unit. You can always find the entire series here.

In our last installment, we briefly introduced the MXML language. We learned that all MXML tags are used as a sort of "short hand" representation of ActionScript code in Flex applications. This time, we continue to look at MXML and it's role as a helpful tool within the Flex programming environment.

All of the material in this article involving code, and indeed all code examples so far in the series, have been written using Flex Builder 3.0. It's worth noting that although we haven't yet devoted an entire installment to the use of Flex Builder, (we will very soon), those new to Flex and wishing to learn more should definitely head straight to the Adobe product downloads page and grab their free 60 day trial. Flex Builder is as good as it gets as far as I. D. E.'s are concerned, and a great way to learn programming is to start messing around with code to try to get things to happen. On that note, we've included a sample application for you to experiment with, but more on that later.

We already know that MXML refers to ActionScript code, but in what way does it do that? To better understand this concept, it helps to know a little about the kinds of situations in which you'd use MXML in Flex. In other words; what types of MXML "documents" you are likely to create.

The most common types of MXML documents that can be created for use in Flex applications are application documents and component documents. Every Flex application that uses MXML requires an application document, but not necessarily a special component document, as we'll soon see.

Component documents are handy though, as they can used for creating customized components as simple as a Button control, or for more complex tasks, like dividing an application into modules, which can go a long way into ensuring that an application will run quickly. The included sample application makes use of a component document to define a custom Button component. An important concept to grasp is that both application and component documents are extensions of classes and are in fact classes themselves.

Application and component documents have root tags that are named after their base classes. In the case of application documents, the root tag always extends the Application class. Component documents, on the other hand, have root tags named after whatever class the given component extends.

When you create a new project in Flex Builder, the code automatically generated is an application document, and it looks like this:

Among other things, this code defines the application. The first line is what's known as an XML declaration. Technically, you can code an MXML or XML document without including this, but it's considered a best practice to include it, (and Flex Builder does this automatically for you). The declaration simply tells the parsers what version of XML encoding, as defined by the W3C, you're using.

The next line is the starting tag of the application. In addition to marking the beginning of the application, because it is the root tag, the default namespace for the document's classes is defined here as well. Earlier in the series, when we were discussing package declarations, we mentioned the importance of declaring them within a unique namespace in order to distinguish them from similarly named packages. Just like if you are in the room with more than one person named "Tom", for example, you'd address the person you wish to actually talk to by saying something more specific than "hey Tom"! The same goes for referencing objects within an application. So therefore, the code that reads:

can be translated into English as: "Within this instance of the Application class, the XML namespace uses a tag called "mx", and has as a part of its identity, the phrase - 'http://www.adobe.com/2006/mxml', which is a unique name that is unlikely to be a part of any other namespace". The "layout='absolute'" declaration is what defines how the child objects of the application are to be laid out, meaning that their location depends upon a specific "x/y" coordinate. Other possibilities include "layout='horizontal'", which lays out child objects horizontally, and "layout='vertical'", which lays the child objects in a vertical orientation.

The point about the application tag referring to an instance of the Application class is an important one to understand in order to see how MXML tags work within an application. Remembering that tags refer to a class's objects will help to make sense of what we are looking at when we see MXML code.

The information that follows (<mx:Application), and comes before the (>) on that line are known as tag attributes. As we'll soon see, an MXML tag can hold information in attributes, as in the above example, or in content tags. A tag's attributes are anything that comes before the end of the opening tag, and a content tag is the code that is placed in its own separate tag, and then placed between the opening and closing tags. (<opening tag> <content> </content> </closing tag>) In most cases, the results are the same if you use attributes, or if you embed the content in nested tags. Consider that the following code:

means the same as this code:

Both of these examples refer to an instance of the Button class' properties (label), they just do it differently. In the first example, the property is listed inline, whereas in the second, it is nested. The choice to code your MXML in the form of attributes or within nested tags may have to do with the complexity of the properties and methods you need to access within the tagged object. For example, I may do this:

But, if things got a bit more complex, I might do this::

So, in a sense, just as MXML makes bringing ActionScript into your application much easier, having a choice between using tag attributes and using nested tags can also make things go smoother.

An important part of most application documents is completely ignored by the parser . We've discussed "comments" before as they apply to ActionScript, and just like other markup languages, MXML has them too. By typing (), just as in HTML and XML, the content within those tags will be ignored by the parser.

Another important tag to be familiar with is the <mx:Script> tag which is followed up by what's known as the "CDATA" section. When you see something like this:

what you are seeing is a place where you can put ActionScript code into your MXML application. The script tag let's the MXML parser not to treat it's contents as markup code. Content within the CDATA tags is interpreted by the ActionScript compiler instead.

Hopefully we've covered enough ground since the beginning of the series so those that are new to Flex can start to make sense of an actual application when viewing the source code. As mentioned earlier, we've included an example application in this post for you to work with. It's a calculator that doesn't work yet; it needs to have the logic programmed into it! It looks nice, and a few of the buttons do stuff to get you started, but you'll need to figure out how to use ActionScript and MXML to get it working properly. This is a great way for beginning programmers to gain an understanding of Flex beyond simply reading about it. To program this calculator you'll have to think about what it needs to do exactly, at every moment, and come up with a logical sequence of events. You should be able to get everything to work by manipulating some variables and functions in the event listener, but feel free to take any road you wish to make it work.

1- There is a custom component in this Flex project called "CalculatorButton", and it's in a small MXML document called "CalculatorButton.MXML". (note the correlations between the application document and the component document).

2- There are several "correct" ways to get this to work, and you can learn a lot from figuring out different versions of the same application.

3- I skipped the "M" buttons in my version because I never use them on real-world calculators anyway, although by all means, go nuts!

4- Once you can get it to add, subtract, whatever, you're close to being able to get it all to work!

5- You may have to create a sub-folder called "libs" in your project folder if Flex Builder doesn't create one for you, otherwise your program may not compile.

6- "Getting the calculator to work" implies actually getting it to do math correctly, not simply displaying something like "I'M A ROCKSTAR!" when you click any of the buttons, apparently.

7- Good luck!

The Sample Application

To get started with this example application using Flex Builder, click on the "download source" link and choose "save to disk". Make a note of where the zip file gets stored. Open up Flex Builder, and under "file" choose "import", and "Flex project". Make sure "archive file" is selected on the next screen and browse to the zip folder that holds the application. If everything is as it should be, you should be able to click on the "finish" button at the bottom. You should see the Flex project appear in Flex Builder's navigator window. Click on the project icon to expand the view into several folders. Click on the src folder, and then click on Calculator.MXML. This is the main application file. Notice the other MXML file - CalculatorButton.MXML. From here you can experiment with workspace views, namely "source mode", and "design mode". Enjoy!

In the next installment, I'll share the results of my attempt at making this calculator work. We'll get into using Flex Builder as it applies to this project, and we'll set the course for more discussions on using the tools of Flex.

View Source - Download Source

Glossary of Terms

XML - Extensible Markup Language. A markup language (or perhaps, pseudo-language), in which you create custom tags to define the way data is carried.

MXML- An extensible markup language created by Adobe for use within the Flex framework. Much speculation surrounds the meaning of the "M", or perhaps "MX" in the name, as no official acronym has been announced.

CDATA- The section of a document which the parser doesn't interpret as XML or MXML, so that a programmer may put ActionScript code code in.

application document- The main MXML document in a Flex application, that extends the Application class.

component document- An MXML document that is used to create custom components.

module- A section of code within an application that is set apart to facilitate an applications run time efficiency.

markup- elements of language that are used to determine the layout of data.

tag- In markup languages, tags such as (<,/>) are used to define the beginning and end of important content.

attributes- In MXML, a tag represents an object, and attributes are the properties/methods of an object listed before the end of the opening tag.

nested tags (content)- In MXML, a tag represents an object, and nested tags refer to the properties/methods that are listed between the opening and closing tags of the object.

XML declaration- A technically unnecessary, albeit proper declaration to include in an XML document that announces the particular encoding that will be used as set by the W3C.

Cuzillion is a tool for quickly constructing web pages to see how components interact. Browsers have unexpected behavior in everyday situations (for example, inline scripts block all rendering in the page and nothing can download in parallel with an external script). Sometimes the behavior differs across browsers (Internet Explorer 8 downloads six items in parallel whereas Firefox 2.0 only downloads two in parallel). Cuzillion lets you observe these behaviors and share sample pages with others

A great example of how Cuzillion is useful is looking at the impact inline scripts have when they follow a stylesheet in Internet Explorer. Typically, a stylesheet followed by any other resource results in both resources being downloaded in parallel in Internet Explorer. (In Firefox stylesheets block parallel downloads, so this performance optimization is only applicable to IE.) Here’s a Cuzillion page that shows this: stylesheet and image downloading in parallel. Both the stylesheet and image are configured to take 2 seconds to download. Since they download in parallel the page takes about 2 seconds to load as shown by the “page load time”. But look what happens if we put an innocent inline script between the stylesheet and image: stylesheet, inline script, and image. Now, in Internet Explorer the stylesheet and image are downloaded sequentially, which means the page load time goes from 2 seconds to 4 seconds. If the inline script is simply moved above the stylesheet the two resources are downloaded in parallel again, and the page load goes back down to 2 seconds: inline script, stylesheet, and image.

Overview

As Flex developers we strive to create user experiences that are engaging and efficient.  The mandate of this mantra requires us to take startup times into account.  When we build our applications, the last thing that we need is for our users to get bored and frustrated before they even start using our applications.

We’re all familiar with the DownloadProgressBar that shows up during preload.  Let’s talk about how to make it go away faster and get users working with our applications in the shortest amount of time possible. 

When thinking about application startup optimization, there are a couple things to strive for:

1. Minimizing download time
2. Deferring instantiation

That being said, let’s take a look at the techniques and things to watch out for.

Download file sizes and Internet connection speeds can really affect the time it takes for a Flex application to start up.  Unfortunately, those are two factors that we have hardly any control over.  The good news is we have a couple of things that kind of help us in this realm, although they have some drawbacks. 

First, there’s caching mechanisms in the modern web browser.  In an ideal end user situation, their browser cache is turned on, so your files can be cached locally on their machine which saves time up front.  The bad news is you really cannot rely on the fact that an end user’s browser will be pulling your files from the cache most of the time.

Second, the Flash Player was built to stream frames.  In other words, the Flash Player can start your Flex application while it’s still downloading the application SWF.  The bad news, is until enough of your application has loaded to show frame two, the only thing the end user will see is the Preloader screen.  The reason being, in a standard Flex application there is only two frames.  Frame one is where the SystemManager and the preload process lives, it is the frame that is running when you see the “Loading” display.  The second frame is where your application lives.  This is why minimizing what needs to occur before the preload process completes is crucial.

So what is a developer to do to move on to frame two?

Beware the Embed

The Flex framework makes available to you a way to compile assets such as images, mp3 files and fonts directly into your application SWF.  Although this comes in handy with making sure that the end user will have a copy of your assets this is a very good way of causing your application to remain in “Loading”.

For example, take this application that contains an embedded mp3 file that’s just over 9MB.

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_EmbeddedMp3/InsideRIA_EmbeddedMp3.html

If you notice, the application remains in the “Loading” state for a very long time.  This is due to the fact that the application cannot move on to frame two until the 9MB or so of extra SWF has been downloaded.  In the above case, keeping the file externalized and loading it in at runtime would have been a better option to decrease startup time. 

Although it may be highly unlikely that you’ll want to embed a 9MB file into your Flex app, imagine an app that has several embedded SVG images, or smaller mp3 files used as sound effects.  Here’s another example, embedded fonts, which is very common.  Let’s talk about fonts.

Use Less Character

When you embed a font in Flex, you are given the whole range of characters supported by that font.  Although that might be what you’re trying to accomplish with your application, are you sure you need all the characters?  For instance, in an English-only applications are you sure you really need to spend time loading data for Chinese characters?

Here’s an example of an app that embeds two different font files with no character restrictions:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_FontEmbed_NOT_Limited/InsideRIA_FontEmbed_NOT_Limited.html

Now, here’s an example of the same application with a limited character set.  In this case, the font is only being used in some labels that just display numerals, so the character set was limited to use just numbers and the period:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_FontEmbed_Limited/InsideRIA_FontEmbed_Limited.html 

The thing to note here is if your browser cache is turned on, the difference between the two is negligible, however, if you delete the cached content between requests, you’ll see some serious startup time differences since the SWFs differ about 200KB in size.  In my tests I was averaging about 500ms of savings by using the above technique.

Now that we know to limit the sizes of the files we’re serving up, how can we further decrease download requirements?

Caching the Framework

As of Flex 3 you can now cache Adobe signed framework RSLs into a Flash Player cache.  The beauty of this is twofold.  First, signed framework RSLs cached in the Flash Player cache are shared among all Flex applications that are configured to use them.  In other words, if someone else’s app had already pulled down the 500KB or so of signed framework RSL, and the RSL is still in the Flash Player cache, your application can use that cached RSL.  Second, if someone clears their browser cache, it does not affect the Flash Player cache.

There are some caveats to Flash Player framework caching:

• The Flash Player must be version 9.0.115 or higher.

• Framework caching depends on a signed RSL.  In general RSLs increase application startup time since the whole library in an RSL is loaded no matter what.  In other words, even if you’re not using DataGrid and Tree, those classes are getting loaded.

• If you are comfortable with relying on browser caching, then that’s usually going to be a faster startup time due to the nature of how RSL libraries are loaded as noted above.

So, here’s an application that uses no Framework caching:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_NOT_FrameworkCaching/InsideRIA_NOT_FrameworkCaching.html

Here’s the same application using Framework caching:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_FrameworkCaching/InsideRIA_FrameworkCaching.html

Overall, you benefit from Framework caching if the end user has browser caching turned off and/or their Internet connection speeds are slow.  For instance, I had caching in the browser turned off and after the initial download of the signed Framework RSL I was consistently saving a good 400ms or so.

Use Modules

Another way to minimize that up front load time is to break your Flex application into Modules.  A benefit to using Modules is that you have control over when a Module is loaded into your application and also unloaded.  In addition, you can optimize a module to work with your application, further decreasing the amount of data that needs to be downloaded by decreasing the size of the actual Modules SWF files.

Here’s the same application from before, but now we’re using Modules and no Framework Caching:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_Modules_NON_OPTIMIZED/InsideRIA_Modules_NON_OPTIMIZED.html

Now here’s that same application using Modules, but in this case the Modules have been optimized for this specific application:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_Modules_OPTIMIZED/InsideRIA_Modules_OPTIMIZED.html

If we keep caching turned off, the startup time gain I was getting by using Modules was about 500ms.  Also, even though the optimized Step1.swf module is about 125KB smaller than the non-optimized one, there really didn’t seem to be any difference between the two when testing with my high-speed Internet connection.

Last point to make about Modules is the reason they were faster was because I could load them in just in time.  In other words, the only Module loaded at startup was the Step1.swf Module.  So in this case of Modules, the end-user saved on startup time, but will end up paying for it when they move from one Module to the next since each new Module will need to be loaded in a JIT manner.  In the case of my app, this penalty is when the user moves through each of the steps 1-5 for the first time.

So now that we’ve talked about how to improve our application startup time by decreasing the download requirements, let’s move on to how to improve startup time via our application logic.

The number one thing you can do to help minimize the amount of time from when data is downloaded to when the user can actually use the application is by deferring instantiation.  The concept behind this technique is not creating objects in memory until they’re actually needed by the application. 

Although deferred instantiation techniques will cause little - and oftentimes unnoticeable - delays throughout the use of the application, this is often considered more acceptable behavior than having a long application startup delay.  The other benefit to deferred instantiation is optimized memory utilization.

When thinking about deferred instantiation, the number one thing to keep in mind is navigator containers such as ViewStack and TabNavigator.  Sometimes developers are tempted to set their creationPolicy attribute to “all” so that they can access children without having a bunch of runtime exceptions caused by null values due to non-existent child components.  The problem with this practice - other than increased memory utilization - is all the child components of the child containers in the navigator are created upfront, before the Preloader display is removed and before the application moves to frame two.

Here is an example of the app with creationPolicy=”all”:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_CreationPolicy_ALL/InsideRIA_CreationPolicy_ALL.html

The good news is that the creationPolicy in your navigation containers is not set to “all” by default.  However, one thing you’ll notice, especially if the navigator children have many children or much associated data is that now when you go from one of the navigator child views to another, is that on first viewing you may see a slight delay as the children of that view are instantiated. 

Here is an example of the app we’ve been working with creationPolicy=”auto”, the default:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_CreationPolicy_DEFERRED/InsideRIA_CreationPolicy_DEFERRED.html

That being said, there’s a way to have your cake and eat it too: ordered creation.  Basically, ordered creation in a navigation container is a two pass beast and tricks the application into turning off the Preloader and moving on to frame two.  During the first pass, the navigator’s immediate child views are created. It is at this point that the application thinks it can display and ends up moving to frame two.  Then on the second pass the navigator’s child view’s children are created. 

In this scenario, if we were to use bullet time, you’d see the application initially with instantiated but empty containers, and then you’d see their children pop into view as the Flash Player works its way through the instantiation queue.

Here is an example of the app we’ve been working with creationPolicy=”queued”:

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_CreationPolicy_ORDERER/InsideRIA_CreationPolicy_ORDERER.html

All in all, ordered creation is perceived as the fastest option of the three navigator children instantiation choices.  Surprisingly, it’s even slightly faster than deferred creation which I guess makes sense since the first navigator child view’s children need to be created with deferred instantiation before moving to frame two whereas in ordered creation that is not the case. 

In my tests, with the browser’s cache turned off, startup time in non-deferred creation was taking around 1100ms, deferred creation around 500ms, and ordered creation around 270ms.

One last note on deferred instantiation in navigation containers: if you’re concerned with memory consumption, deferred instantiation A.K.A creationPolicy=”auto” - the default setting - is still the way to go in your navigation containers.

Recently I discovered a blog post by a gentleman named Dirk Eismann that created a cool little Flex Builder plugin that I use every day.  Flex Builder TODO/FIXME plugin. (http://www.richinternet.de/blog/index.cfm?entry=911D4B57-0F0D-5A73-AF6F4D4D04099757) 

Anyway, his post mentioned taking advantage of the streaming nature of the Flash Player to minimize startup time in your Flex applications without having to use Modules or framework caching. (http://www.richinternet.de/blog/index.cfm?entry=FF295F89-DAD8-CCDC-960413842BC0D478)

The key thing to note about this technique is that it deviates from the standard two frame Flex application movie.  Although I can’t take credit for his technique, I decided to expand his code snippets and details into a working example for this blog post which I got "mostly" done.

Here is the application I’ve been working with in a seven frame Flex application!

http://labs.realeyes.com/examples/InsideRIA/Part2/InsideRIA_MoreThanTwoFrames/InsideRIA_MoreThanTwoFrames.html

The main thing to notice when you run the application is that you can interact with the first form that’s in frame three while all the other forms in the subsequent frames are loading in.  I slowed frames four through seven down by embed