I'm working with a large flex applications and I have noticed that one of our largest components (with lots of child canvases) takes about 6 seconds between the initialize and creationComplete events. I've been doing some reading and have found that having lots of nested canvases can cause slowdowns, but i'm not sure if this is where the slowdowns would be? Anyone have any suggestions on speeding this up, or even diagnosing exactly where the slowdowns are coming from?
It's been my experience that nested containers with dynamic sizing are the most common cause of these types of lags. Some things to try:
Set explicit sizes/positions for your containers/components whenever possible. This reduces the incredible amount of measuring that goes on within the framework during the creation process.
Reduce the number of nested containers. Sounds obvious, but it's amazing how much you can cut away when you start looking critically at how your UI is set up. Specifically, are there HBox and VBox containers you can get rid of by simply setting explicit positions/sizes for the child components? Do you really need to use a Form container?
Switch your containers to the much lighter weight Spark Groups instead of using the heavier weight Canvas where possible.
Hope that helps. If not, post some code so we can dig in to your particular issue.
The biggest thing to consider is to use VBox's and/or HBox's in place of some dynamically generated x's and y's. VBox and HBox are much more efficient. Look into it!
Adding many display objects to the display list all at once can take a long time, especially if we're talking about Flex containers that have layout and scrolling logic in the mix. Since you say you're using many Canvas containers, that could certainly be the issue you're running into.
I know that a lot of developers abuse the creationPolicy property. Normally, it is set to "auto" which allows Flex to defer instantiation of a container's children until a very short time "later". Often, before the next frame, so you don't even see the difference. Do you happen to set creationPolicy to "all" anywhere in that hierarchy? This could be forcing the Canvases and their children to be created immediately.
Related
I am adding and removing elements dynamically in a flex application
When adding an removing items in flex component there is a flickering happening on the screen(Not all the Time only on first loading of the application). On research I understood that this is because of the time delay for two updates. One for removeAllElements and other for addElement. Is there any way to make it as one update to remove the flickering issue?
thanks
It's good practice to use DataGroup as a base class for list components. The huge benefit of it is that it has virtual layout. What means if you have 1000 items in your list, framework will create only items which can be fit in current screen ( for example 20 ). And than reuse them when user scroll list. So most likely using DataGroup will solve you problem.
I'm trying to add a custom background to my horizontally laid out container. There are two ways mentioned to accomplish this:
Use a SkinnableContainer with a HorizontalLayout
Use a Group with a Rect and another HGroup inside it.
Which is a better option according to memory? Also, is placing multiple groups, hgroups and vgroups in a nested fashion a major flaw in design?
Thanks in advance!
Which is a better option according to memory?
You'll have to test and see, but from a theoretical approach; a SkinnableContainer will perform a lot more processing than a group. My first approach would be to use a group with a Rect inside it. Or, if you're doing mobile development, use a group and draw a Rect on top of it using the graphics API.
Also, is placing multiple groups, hgroups and vgroups in a nested
fashion a major flaw in design?
Not a major design flaw, but it could very well contribute to the lack of performance in an application. It it becomes an issue, you should evaluate your use of containers and see if you can minimize. Sometimes using a basicLayout and writing a layout algorithm will give you a lot more performance, and flexibility. It may very well take longer to write, depending on the complexity, though.
We are building a flex project and would like it to render faster. We do have situations where we reference parent module size properties to size current module containers, as well as current module size properties for a bunch of attributes including font size and element positions and sizes.
Would it help to create temporary variables for
a) pcw=parentcontainer.width, pch= parentcontainer.height
b) ccw=currentcontainer.width, cch=currentcontainer.height
and reference to pcw,pch,ccw and cch while doing positioning. Will that help?
Also given the bulk of the positioning will be done in mxml, will setting these interim variables in initialization function, allow them to be used in mxml such that they will resize as browser size is changed. Thanks for pointers
I'm not sure if you're using the term "Module" a a generic term to refer to a component, or if you are explicitly referring to classes of the Module class.
It breaks encapsulation if a container is aware of it's parents. In Flex, a parent is always responsible for sizing it's children; and a child should never size itself.
You had code like this to access the parent's height and width:
pcw=parentcontainer.width
parentcontainer.height
I can't imagine how saving the parent's height and width values would speed anything up.
I also find it hard to envision a situation where knowing the parent container's width and height is helpful. Often a container has more than one children. It is important to know how much size a component has for laying out it's own children, not how much space the parent has.
The appropriate way to size and position a component's children is to override updateDisplayList(). updateDisplayList() has two parameters: unscaledWidth and unscaledHeight; that is, in essence, the height and width of the component. You should size and position the component's children based on those two values.
Of course, doing so often relies on ActionScript; not MXML.
Your primary question seemed to want to improve performance. There are many factors involved in the performance of an app. Using ActionScript for layout instead of MXML could be one factor that may help improve performance. Minimize your use on binding is another thing that can sometimes help performance.
Have you used the Flex Profiler? Have you stepped through code? Does doing these things help you determine what exactly the performance issue is?
Unless your application changes it's shape a lot, there shouldn't be any problems laying out with Flex if you use proper skinning/component/layout standards.
Most of the problem isn't from Flex, but the code most people add onto their own application that renders the whole system slow. Make sure you brush up on Flash performance improvements (like data structures, limiting binding, proper architecture, object lifecycle, etc).
I know there are a lot of questions about dynamic sizes for Flex components, but this one is quite specific and the other answers aren't a whole lot of help. Briefly, I need a List that resizes to exactly fit its content, unless that height exceeds its (dynamically sized) parent container. My requirements are as follows:
The component extends List, or at least acts similarly.
variableRowHeight and wordWrap both equal to true.
The height of the list cannot be less than minHeight (roughly 32px for scrollbar arrows).
The height of the list cannot be greater than the height of the parent container .
Note that the parent container can be resized dynamically.
The height of the list should be updated as the size of both the contents and parent container changes.
Live updating would be preferable but not necessary.
There should be no scrollbars if the content height is less than the parent container height (sounds obvious, but I've had trouble with this too).
The trouble is that with variableRowHeight and wordWrap, it's very hard to know the size of the content at any given time. If the parent container's width is reduced, a line wrap may occur in the list which will change the height of the content. I know I can measure the height of the list content using measureHeightOfItems() + viewMetrics.top + viewMetrics.bottom, but when should I calculate that? What events should I listen for? And the thing I've had the most trouble with - when should I calculate it to set the size initially (i.e. just as the content has finished populating)?
I've been tackling this for months now on and off, but can never find a solution (though I've come close with chunks of code of varying degrees of incomprehensibility). I'm not asking for someone to create a full component for me, I'm just hoping someone has the right pointers to let me know how I should go about determining and updating the size. I'm happy to do all the prototyping for you and discuss the results :).
Custom Flex components are definitely their own beast. You have a lot of dedication to spend months working on one!
If you haven't seen it already, you should certainly take a look at the Flex Component Lifecycle. This will answer your questions about where to execute code. I believe that measure() and commitProperties() are going to be important for your component.
I also find validateNow() to be a very useful function when managing components with dynamically sized children and/or parents. I have not yet figured out when the optimal times to call this function are but it seems to be necessary when calculating sizes of Flex components. There's an informative article about it at judah's blog.
Best of luck!
Update -- I stumbled upon a seemingly great article about Flex component lifecycle at DevelopmentArc that I'm adding to my own reading list.
I was told that there is an increase in performance when using Canvas versus HBox or VBox when laying out out the position of children. As a result, a number of our components have been converted over to using Canvas. However, now there is code being added to calculate the x and y positioning of some of the child elements based off of the width and height of other children. Is it worth using a Canvas to increase performance if code needs to be added to determine the coordinates/positions of the children? Is there a better method or technique available that should be practiced other than just minimizing the number of ui components added and specifying positioning absolutely?
There are a number of middle-of-the-road techniques, one of which is to use rendering-type components, such as TileGrid or ItemRenderers, if your layout fits a certain formula. If you're using forms, try using the Form layout component instead of using a custom layout.
If you do need to use the layout engine in Flex, the way to optimize your usage is to remember that certain techniques are used by the framework in increasing performance load, loosely following the below list, the last being the most performance intensive:
absolute positioning (<Canvas>)
relative positioning (<VBox>)
constraint-based positioning (right=0)
advanced constraint-based positioning (<constraintColumns>)
Using relative positioning is usually not that performance intensive. If you are finding that it is, it could be that you're using too many nested containers. Look at your layout architecture and try to find out ways in which your objects may be "over-laid out", and simplify them. A good tool for this is FlexSpy, which lets you introspect object layout at runtime.
Another common performance bottleneck is that your application is attempting to do some number-crunching at the exact same time that your GUI is attempting to respond to user interaction. Although no green threading frameworks exist at the moment which enable you to run UI and logic in separate 'threads', you can use a good architectural framework such as Cairngorm or Mate (there are many) which uses Commands instead of straight up methods, so that functionality execution which may take up processing cycles waits until the UI has finished responding to the user.
A couple things you want to keep in mind while optimizing a Flex UI:
Avoiding excessive nesting of containers. Consider using a Canvas with absolute or constraint-based positioning over nesting lots of HBox / VBox elements. However this doesn't mean you should NEVER use VBox/HBox. You can mix and match, such as using a Canvas as the main container and positioning child Boxes inside them as needed, just try to avoid too much nesting.
Using the UIComponent model properly in custom components. In particular, using invalidateProperties(), invalidateSize() and invalidateDisplayList() so that their companion functions (commitProperties(), measure() and updateDisplayList()) are invoked at an optimal time for the Flash Player. Deepa gives a great talk about this here:
http://tv.adobe.com/#vi+f15384v1002
She explains how making heavy use of the invalidation scheme allows the Flash Player to execute your code at an ideal time, i.e. not in the middle of a screen update. These principles are used by all Flex components and can/should be leveraged regardless of the framework being used.
To make sure I understand:
You heard that Canvas can position children faster than [VH]Box
Canvas only does absolute positioning
Some (many?) of your components have an absolute position, so you switched to using Canvas
But some of your components have a relative position, so you need to write code to position them
Is that correct?
Anyway, assuming I'm correct (which may not be the case), the first thing you want to do is pick the functioning interface which requires the fewest lines of code, then decide if it's "good enough". You want the one with the fewest lines of code because studies have shown that there is a correlation between lines of code and number of bugs (and you don't want bugs). You want to see if it's "good enough" because, if it IS "good enough", you don't need to do anything (if you do try and make it faster, you're committing Premature Optimization).
But that's probably not what you wanted to hear :)
So I'll also suggest that, if you want to stick with Canvas-based layout, you try sticking all the relatively positioned content inside [VH]Boxes, which are then absolutely positioned inside the Canvas. There's a good chance the code Adobe has written is faster than code, so you should try to take advantage of it.
But the only way to know for sure is to try it and profile it.