FLAws: Forms

Need I say any more? j/k 😉

Quick disclaimer: There’s a good chance I’m wrong about some of how this all works, so please feel free to correct me, I do not want to spread incorrect information or FUD.

Forms in Flash are a little like the apple in the garden of Eden – tempting and nice to look at, but all hell breaks loose when you try to eat ’em. It doesn’t help that the whole time this little snake called Macromedia is whispering in your ear, telling you to take a big bite.

Adding Forms to Flash was a great idea – it provides a nice, structured development environment for state based applications, it makes implementing MVC clean and simple, and it makes the technology far more accessible to programmers familiar with environments like Visual Basic.

Unfortunately, the implementation is – hmm, how to put this politely – substantially sub-par.


You see, Forms suffer from a series of fundemental flaws that make them almost completely unusable. Without bothering about missing functionality (which is open to debate), here are a few of the issues which hinder their use:

  1. Compile Time (aka publishing time): Form-based applications can take up to 10 times as long to compile as a traditional time-line based Flash app. For example, Beau recently did a test with the application we’re currently working on where he recreated the same app using forms (same component load, same scripts, etc). The original application took 2 seconds to compile whereas the forms-based copy took almost 15 seconds.

    So what’s happening here? Maybe Burak can shed some light for us. From my understanding, form-based applications don’t compile in any special manner. Every form is simply compiled into a MovieClip symbol in the swf. So what takes so long?

  2. Initialization Time: While the increased compiling time is irritating to me as a developer, it doesn’t impact the user – but the massively increased initialization time for Form-based apps certainly does. In the same test mentioned above, the initialization time for our original app was 1 second, the forms-based one was quite erratic, taking between 5 and 20 (!!) seconds to initialize. This is on a fast P4!

    To the best of my knowledge, this is due to the fact that in a forms based application, all of the forms are instantiated on the first frame, so every single component in your application initializes itself on the first frame. Pair this with the style issues I noted a few days ago, and you can see how this could cause a huge slowdown when the application first loads.

  3. General Slowdown: Another major flaw with forms (and please correct me if I’m wrong here), is that with a form application keeps all of your content on stage at all times, it simply changes forms visibility to hide or show the appropriate bits. Unfortunately, every piece of content that’s on your stage (and especially the new components) use processor power, even when they are sitting completely idle. As your application grows, everything slows down.

    This is compounded by the fact that hidden content is not moved off stage. Flash exhibits an odd behaviour in which it apparently continues to devote processor cycles to drawing invisible content in the stage area. You can test this by creating a complex animation, and testing the swf with the animation’s _visible property false. Test it again, but this time set its _x to -2000 – you should see a significant speed boost. If hidden forms were moved off stage instead of simply made invisible, performance should increase.

  4. No Preloading: To the best of my knowledge, there is no way to preload a forms application without using a second swf. This causes difficulties, especially considering that Beau and I have identified a number of issues with global styles and focus behaviour when you load applications into another swf. The best solution I have found is to create an external preloader swf that loads the application into a level. This solves a few of the issues that we found, but not all of them.

I think Macromedia had a great idea with forms, and I would like to see them succeeed. I really like the fact that you can easily define external swfs as forms in your application, and the ease with which you can bind classes to them. Forms provide an awesome platform for creating MVC applications, and (with faster compiling) enable faster development of state based applications. There’s just a lot of issues that need resolving before I consider them viable for production.

Again, if you know something I don’t, have a workaround, think I’m wrong (it happens), or can add some knowledge, please post in the comments – it would benefit everyone.

Grant Skinner

The "g" in gskinner. Also the "skinner".

@gskinner

5 Comments

  1. The compiler delay is directly due to the use of createClassObject in that all dependent classes are compiled over again instead of using precompiled SWC components.

    Take any project and replace createObject with createClassObject, it will take 5x times as long to compile. The more components you use the worse it gets.

    cheers,

    ted 😉

  2. Anyone know the easiest way to convert a forms based app back to a timeline app…? it all seemed like a good idea at the time when I was creating one. It works and all and is not terrribly slow, but I wouldn’t like to see it running on P3’s.

  3. Hi Grant,

    Yes, forms have a long way to go… I just wanted to add two other issues to the mix. First, Forms and states are not the same thing and I think it is a mistake to mix the concepts together. When an application changes state elements of a form or forms may be manipulated in certain ways but you may not have to show or hide forms. For example in a FlashCom application the user may decide to close the Network connection to the server. That change represents a change in state in the application. However, that doesn’t mean you have to show or hide a form. You may want to allow the user to continue updating a form in “offline” mode. So forms are really more about organizing a heirarchy of visual elements rather than spreading them over the timeline. They do not represent the state of an application.

    Second, unlike slides Forms have no formal form transition mechanism. Your code has to decide what to show and hide and do all the work of manipulating everything. The form class itself adds very little to the mix. So I think the form class is where Macromedia needs to go back to the drawing board. Loading swfs is not the answer to reducing the memory footprint of forms-based applications. You should have a simple mechanism for instantiating and inserting forms into a heirarchy and for harvesting them. Otherwise the itmeline remains much more effective as a memory management tool.

    Finally, I think we can get some value out of looking at hierarchal state machines. Even though forms are not states I have implemented enterForm/ exitForm methods which I find helpful. Also I have based form transition management on finding the lowest common form in the form tree to be helpful as well. The idea is a rip off of finding the lowest common state in a state hierarchy.

    Yours truly,

    -Brian

  4. Hi Grant,

    Glad to see this discussion finally rearing its bittersweet head. What really bothers me is that when using the forms metaphor, the V2 architecture is forced into your swf even if you are not using any of the architecture. For example, if you want to create a small application under 20 k based on your own architecture, then you cannot use the forms metaphor, because you will already be over your size limit before getting started. I think it would be nice to be able to use the author time metaphor with my own smaller architecture without having my swf stuffed with classes that I am not using.

    I applaud the idea of forms in Flash, but for my daily work, I find them useless. I hope that in the next version forms will be more polished and thought out.

    cheers,

    Jer

  5. FLAcune: Forms

    Grant Skinner poursuit sa croisade et nous propose une nouvelle FLAw concernant l’utilisation des Forms avec MX04. Pour le peu que je les ai essayées, j’ai rapidemment pu voir que l’idée est bonne et attirante, mais les perfomances la rende…

Comments are closed.