Explanation of Stateless and Stateful skins
There are several approaches to style and skin Flex applications. Adobe has also been nice enough to provide some special skinning extensions and kits to work in conjunction with the CS3-CS4 tools such as Flash, Fireworks, Photoshop and Illustrator.
These extensions provide templates and some export commands to assist the workflow of creating graphical skin and exporting them out to bring into your Flex application. Most of these workflows consist of using a “stateless” approach. This means there is an individual asset for each state of a component, such as an image for the up, over, down, and disabled states of a basic Button. The stateless approach can be used with AI, PS, FW and Flash. The nice thing about using it with AI and Flash, is that you can keep the graphics vector within a SWF, if that is your preference. In FW and PS, they will export as bitmaps.
As for the stateful approach, this had been my preferred choice for the past year or so. This requires the Flex skinning extension kit for Flash where it provides a Make Flex Component Command and provides the FlexComponentBase to your file which allows Flex to communicate and translate with the state and transition frame labels without having to write any additional script within Flash or Flex. This approach also utilizes the Embed Skin Class approach within the CSS v. the Embed Source as with stateless.
Example CSS for a Button
Stateful CSS:
Button.
{
skin: Embed(skinClass=”Button_skin”);
}
Stateless CSS:
Button
{
disabledSkin: Embed(source=”flex_skins.swf”,symbol=”Button_disabledSkin”);
downSkin: Embed(source=”flex_skins.swf”,symbol=”Button_downSkin”);
overSkin: Embed(source=”flex_skins.swf”, symbol=”Button_overSkin”);
upSkin: Embed(source=”flex_skins.swf”, symbol=”Button_upSkin”);
}
As you can see, in the stateful skin, you only need one symbol for all of your states of that particular component. The states are designed within the timeline of the individual symbol within Flash. Inside that symbol, there are two informative layers for Flex to communicate with and to be able to assign the appropriate state/transition to that particular component.
Those layers are states and transitions. A typical button would have frame labels of: up, over, down, disabled, selectedUp, selectedOver, selectedDown, selectedDisabled.
The stateless approach would require creating a separate symbol for each state of that particular component.
Now, for the main point of this post…
Issues with Stateful skins
The stateful skin approach was a channel later introduced by Adobe as one of their recommended workflows, and had seemed to be the most optimal in regards to efficiency and workflow in my opinion. Unfortunately, we (Project Team @ EffectiveUI) have discovered a major flaw with performance using stateful skins within a large Flex application where there are many instances of a component using a graphical skin. In smaller applications with minimal instances of a graphical skin, the performance hit is minimal and may not be noticeable, so it is proportional to the amount of objects using a graphical skin.
On a recent project, we saw a rather large percentage increase in CPU usage when using a stateful skin on a CheckBox and other components. There appears to be an OnEnterFrame recursion on UIMovieClip, which is the Base Class for a stateful skin. We weren’t sure if it was part of the swc, or how Flex was pulling it in and reading it, so we decided to run a quick test. We swapped out the stateful skin with a stateless version using the same exact graphical information in the fla, but just designed as stateless and compiled to a swf. Once the developer threw that into the app, the CPU usage dropped dramatically! It dropped to the expected percentage which should be almost identical to not using any CSS or external styling in your Flex application, since skins should not hit the CPU usage. So, it seems like we have narrowed down the issue to the use of stateful skins.
(note: There were issues on more than just the CheckBox, but this was one of the components we used to try to narrow down the issue)
The Test
A fellow coworker, Greg Owen – Lead Developer @ EffectiveUI, help me create a test environment Flex application (wrapped in AIR), which will instantiate several hundred CheckBoxes, this should provide enough performance in the app to see a hit on the CPU usage while using the stateful skin swc.
In the test app, we did some variations with stateful skins and here are the results:
Running 100 CheckBoxes + stateful skins – CPU usage = 19%
Running 250 CheckBoxes + stateful skins – CPU usage = 30%
Running 500 CheckBoxes + stateful skins – CPU usage = 50%
Running any # of CheckBoxes*—————- CPU usage = 10%
(*no added styles/skins)
You can download the source if you would like to try the test it yourself. You can go into the MXML and alter the amount of instances of the CheckBox, and you can swap the style sheets used between the stateful and stateless skins.
I have created two sets of skins for this CheckBox to swap out and review the difference in performance. One skin is a stateful symbol within a swc, and the other stateless skin is comprised of eight symbols, one for every state of a CheckBox, within the swf.
Download the source files here:
https://www.patrickhansen.com/demos/flex/SkinningTest.zip
Click below to view Greg Owen’s post about this issue:
http://behindtheui.blogspot.com/2009/03/flex-component-kit-cpu-black-hole.html
As a result, I plan on working with stateless skins from here on out until there is a resolution to this issue.I’m also planning on working with Degrafa and FX-G in FB4 more for skinning as well.
updated: March 2009
Here is the post for: Stateless vs. Stateful vs. Degrafa
*On a Mac, you can open the Activity Monitor under Applications/Utilities and you can check the CPU usage.
Interesting post.
Btw, your last paragraph says:
“As a result, I plan on working with stateful skins …”
Do you mean “stateful” or “stateless”? I would think you meant to say the latter since the problem is with stateful CSS, correct?
Anyway, I’m trying to push our team, which is primarly Java focused, to consider implementing a very large application in Flex. I’ve been pushing it since I think it could meet our no more than 1 second screen refresh/transition requirements and ease of development, and such.
I’m starting to wonder if their concerns are justified. How large is your application? Do you have any books, articles, and such to guide me in architecting such large applications to be performant and scalable?
One of the things I started doing to allow parallel development is to break the code in module (as I would do in Java/Servlet/JSP) but I’m running in the problem of having to create a TON of namespace. Anyone to avoid this when using packages such as:
com.company.project.events.module1
com.company.project.events.module2
com.company.project.maps.module1
com.company.project.maps.module2
com.company.project.managers.module1
com.company.project.managers.module2
com.company.project.views.module1
com.company.project.views.module2
If I need views from module1 and module2 then I need to create a namespace for both… quite annoying.
Yes, I meant stateless – I did correct it – Thank you.
I forwarded your reply to a developer that I work with, Sean Christmann, who would be a lot more qualified to help you out with your question.
Greg Owen, who also posted about this subject, may get back to you as well.
I’m primarily a designer who messes around with some development, but only to a certain extent.
Sean Christmann’s blog:
http://www.craftymind.com/
Thanks
Eric
When addressing performance on large scale applications you will need to lean heavily on the power of ViewStacks. These are usually linked pretty tightly to whatever navigational elements you use whether its a tab navigator, accordion or tree navigation. Controlling how views load in and out of viewstacks is going to cover most of your performance concerns as an application-wide policy.
Modules are not a good solution for managing developer workflow, they’re better for managing application architecture. Modules work well where there is a logical separation of different areas of the app(like portal apps), they don’t work well when you want to have 2 different developers working in the same area. Otherwise, like you’ve noted, you just end up bloating your namespaces
Eric,
If you’re doing module development, each module would only use the views and event, etc., necessary for that module, so there should be no namespace bloat.
From the main app point of view, you shouldn’t be referencing the modules. The modules should be written in a generic way, built on an abstract architecture.
Why are you referring to specific module classes from the main app? You shouldn’t know, or care, about specific module implementations.
🙂 just for clarification, this kind of problem is for stateful skins using graphical skinning? 😀
coz im using degrafa for my skins.. 😀
and im a bit concerned too.. 😀
You are correct.
This post only addresses concerns and issues that we have seen with stateful graphical skins in Flash to Flex workflow.
We have not seen any alarming impact using Degrafa, so at this point, I think you’re good.
You can download the source Flex test app and try to use a Degrafa skin for the CheckBox we threw in for a test and see.
If I get some time this week, I’ll mess with that too.
😀
but actually i have trouble skinning checkbox using degrafa..
since u actually need to draw the icon of the checkbox.. and i dont know how to do it with degrafa
so i just used the flash drawing tool of flex. 😀
Anyway, your blog is enlightening..
I wish you have more to share regarding flex skinning.. 😀 More power
You can solve this issue and still use Degrafa in a couple ways.
1) You can just use a bitmap image of the checkMark icon and throw that into your skin as an external image.
2) You can draw the checkMark icon in another tool like Adobe Illustrator, and then export the SVG path data and take than into Degrafa.
http://www.degrafa.org/samples/
and scroll down to the Dynamic Graphics section. There are some examples using SVG path data to draw complex shapes and imagery.
I will definitely try to post as much as I can about skinning/styling in Flex.
Also, have you visited http://www.scalenine.com ?
There are some great resources from Juan Sanchez about Flex skinning there. He is also one of the designers behind Degrafa, along with a coworker of mine.
the things is, i avoid using external graphic image.
what i actually dont know is how to point the icon style attribute to a GraphicBorderSkin (Degrafa).
or if there is another way.. I dont know how.. 🙂
wow.. so you personally know juan sanchez? 😀
amazing.. 🙂
ive visited scalenine a couple of times and i really like their skins. Thanx a bunch!
Yeah – using external images is a good idea, but you cannot always avoid them or the scenarios.
As for your question, you should be able to do this in the CSS. If the component has an icon attribute, then you can set that in the CSS for that style – possibly make a separate name_icon.mxml file just for the icon and keep it separate.
Working with Juan Sanchez has been awesome! I have learned SO much from him and he is a very humble, creative, smart, and a talented designer/developer – not to mention hilarious. I have the honor of sitting a few feet away from him in the Denver Effectiveui office!
Hi,
when you say that the flex component kit is bad do you mean only the component kit for flash or also the others (for illustrator & photoshop)
I have a project that has animated buttons. The animation occurs when the states changes. Does somebody know what the best way is to implement these. first I was thinking about using the flex component kit for flash but it seems that this is bad. So I gues the best way would be to generate an flex component form flash and use the swc in flex. Or is there an other better (for performance) way.
I’m not saying that the Flex Component Kit is completely negative, but I am saying in some instances, it can be bad and take a hit on your CPU.
I think I should clarify a little more on the kit and what it consist of.
Stateless
Stateless skins can be created using Photoshop, Illustrator, and/or Flash using the templates provided by the Flex component kit, but do not rely on the Flex Component Base item in the library of Flash like Stateful skins, nor do they rely on the kit. You can create stateless skins without the kit or templates and you would not need anything special or additional to get them to work except for the correct URL/path in the CSS. Each state of a stateless skin is a separate image (bitmap), or symbol in a swf which is published as AS 2.0.
Stateful
Stateful skins are created in Flash using the Flex Component Kit where it adds the Flex Component Base item in the library which introduces the UIMovieClip Class and produces a swc to be used in Flex. This also must be published as AS 3.0 and each item has a Base Class of UIMovieClip.
We have shown that using the kit with Flash using the STATEFUL technique (swc), can cause some performance issues. If your application is not very large, the performance hit may not be that big of a deal or a concern.
The Kit
So, the kit for using stateless skins in Ai, PS, Flash (swf NOT swc) is great, in regards tot he templates that it provides, but again, you do not need the templates or kit to create the stateless graphical skins.
Unfortunately, you will not be able to get animated transitions using these techniques. You could manipulate the stateless skins in Flash and maybe obtain some animations, but they won’t be as robust or manageable as in a stateful set.
Animations and complex skinning
If you require transitions and animations, then you may want to look into using Degrafa. It is a third party Declarative Graphics Framework, similar to the new FX-G in Flex 4. It is a programmatic approach to skinning rather than using graphics, but it is very robust and allows for a variety of options including many that cannot be obtained using graphical skinning.
Degrafa
You should view some examples from their samples section:
http://www.degrafa.org/samples/
http://www.degrafa.org/source/ButtonLoader/ButtonLoader.html
Multiple skinning approaches for a single application
Also, you can combine up your skinning assets into various external files an techniques, and do the basic ones in the more traditional stateless manner, and only use stateful for the animated items. Hopefully that may not cause such a large impact on your application’s performance. You could also combine Degrafa into this equation as well for the more complex items.
Hope this helps. Feel free to hit me up if you have any further questions.
This has now been fixed. I am not sure which SDK fixed it but it is certainly fixed in Flex 4.
You can see by looking at the EnterFrameHandler:
protected function enterFrameHandler(event:Event):void
{
// explicit size change check.
if (explicitSizeChanged)
{
explicitSizeChanged = false;
setActualSize(getExplicitOrMeasuredWidth(), getExplicitOrMeasuredHeight());
}
if (x != oldX || y != oldY)
dispatchMoveEvent();
removeEventListener(Event.ENTER_FRAME, enterFrameHandler);
}