I have a spark List in which I am adding custom components manually (without an item renderer). Everything is working fine except when I add hundreds of items in the list (based on several calculations), the render time increases to several seconds.
My questions are:
Does flex automatically delay the rendition of components that are added to a list?
If not then, how can I tell the spark list to only render the components once everything is added.
I hope what I am asking makes sense. I am pretty sure the render time is increasing because I have quite a few components inside the custom component. I just need a simple answer to my questions.
One more thing to know is that,
ActionScript 3 runs on flash player based on even-driven. It means that if you run a chunk of code in blocking, anything else, including rendering, will not be executed until the code ends.
This design sometimes causes issues: If a developer adds too much job in one blocking function, the player looks frozen and unresponsive momentarily. (If the code is an infinite loop, it stops until the player detects and throws ScriptTimeoutError, or possibly forever.)
However, for your question, yes, anything will be delayed until the adding job is done. Flex components doesn't basically split the job automatically.
Flex components are rendered in the list according to the Flex lifecycle: http://help.adobe.com/en_US/flex/using/WS460ee381960520ad-2811830c121e9107ecb-7fff.html
There are two reasons your List may be running slow, your components may not be following the Flex lifecycle correctly and the second because virtual layouts are not enabled on your List.
First the hard one:
Your first step should be to ensure you are following the correct phases in your custom components for commitProperties(), measure() and updateDisplayList(unscaledWidth:Number, unscaledHeight:Number).
So long as you are not calling any method named validateNow() on either your UIComponent subclasses or the LayoutManager then your components should follow this just fine.
The second may be that your list layout is not using virtual layout. This is enabled by default in a Spark List component but if you're overriding the layout you should ensure that useVirtualLayout is set to true on whatever layout you're using.
This is the property to enable it:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/components/List.html#useVirtualLayout
This is what it does to speed up rendering many items in a Spark DataGroup component (which a List is):
http://help.adobe.com/en_US/flex/using/WSc2368ca491e3ff92-1483ec4a12136246e76-8000.html#WS685c4ccbb85d340c6617851e121d4b8abae-8000
Related
What would be the preferred (recommended) way to rearrange the components of a QML UI on an event such as a button click?
I do have designed a UI consisting of a bunch of custom components, each of them is bound to a (C++) model. I use anchors to position the components in the ApplicationWindow.
On a button click, I want to add an additional component which, due to its size, makes it necessary to rearrange the existing components. Actually, the button could be understood as switching into a different mode such as the Debug view in an IDE (think of Eclipse).
My goal is to keep the components in a consistent state between views and make the switch as fluent as possible.
I could think of these options:
Design two different views, and use a Loader or State to switch between them. As initializing the models takes some time, they should remain not be deleted during switching. I think, setting them as ContextProperty of the QMLApplicationEngine should take care of that.
Do a lot of rearranging in the onClicked()-Handler of the button. Probably the worst solution but does not require to reinitialize the components and models.
I think the most elegant solution would be to initialize the components in a some kind of container (or model) and then assign different layouts to this container on button click. But I have no idea, if this is possible and how to achieve that.
Edit: I followed approach 1. by using the StackLayout. It works basically, but it seems as if the invisible UI is still running in the background and consuming resources (e.g. requesting Images from my QQuickImageProvider).
Using a Loader eliminates this problem as it destroys the previous UI on every change of the source property. What I do like about the StackLayout however is that it preloads all UIs on app startup. So the transitions are smoother compared to the Loader. Is there a way to disable the invisible UIs?
Your option (1) is the one giving your the most flexibility, since you have two entirely separate UIs depending on state.
As you already discovered yourself this requires keeping all relevant state data in a way that is accessible by both UIs, e.g. in C++ or in globally accessible QML/Script objects.
I would go for that if you envision any more changes or tweaks than just rearranging elements.
If you are sure that rearranging elements will be sufficient, have a look at QML states
It is a bit like a combination of your options (2) and (3).
The state setup allows you very locally to define anchors and other properties for each element depending on a named state.
The button's signal handler then only needs to change which of the states is active, by assigning one of the names to the respective state property.
I've read in the flex developer guide that you sometimes need to override one
of the lifecycle methods like: commitProperties and updateDisplayList
but I've written a few flex apps without ever needing to implement them.
when do I need to override them?
First, I 100% recommend studying this presentation by EffectiveUI:
Diving Deep with the Flex Component Lifecycle
and this by Michael Labriola from Digital Primates:
Diving in the Data Binding Waters
They go into things you'll never find in the docs but that are super practical for understanding the Flex Component Lifecycle.
From my experience, the only time you need to worry about overriding core lifecycle methods is if you are creating components. I make a distinction between Application Views and the Components.
Components are things that need to be nearly perfect, highly optimized, and extremely versatile/abstract.
Views are things that you may only need in one Application, but could reuse if you so desired (LoginScreen, ContactForm, etc.).
Views, for the most part, are just adding things to the display list of a more generic component (Canvas, Group, Container, VBox, List, etc.). You, as a View/Application developer, don't really care about how the "dataProvider" creates it's itemRenderers, it just works.
Components are a different story though. When you create a component, you want it to fit perfectly into that system Flex has set up: the Component Lifecycle. It's pretty tough when you first try to build a component like they do, but after you wrap your head around it it's super easy. Here's how I think of the methods when I develop components:
createChildren()
Called once when component is constructed
Called top down. So if Panel calls createChildren, it's createChildren method will call addChild on all of it's children, which calls initialize, which calls createChildren.
If you created a custom component, say a StarRatingComponent, you might want to add 5 stars to the stage when the component is constructed. So you'd override createChildren() to do add stars to the component you're in. By default, though, all Container components in the Flex SDK add their children here (lists do it a bit differently), so you never have to do this if you're building MXML views or something not-to-be-extremeley-reusable.
The next 3 methods are called 1 frame after properties are set.
measure()
If the parent doesn't have any sizing (percent or explicit), it will need to be sized based on it's children's sizes. This can only happen from the bottom up (took me quite a while to really wrap my head around that).
If the parent has explicit or percent sizes, it skips this step.
You override measure if you want to:
Have measuredWidth or measuredHeight return a useful value. So if you build a custom CoverFlowContainer component, and measuredWidth/measuredHeight aren't set (because measure was not overriden), then if you don't specify any sizing on CoverFlowContainer, it would be 0 width 0 height. So instead, override measure and have it set measuredWidth to radius * 2 or something like that, and now you don't need to give it a size!
If the component does not have an explicit or percent size, measure will be used to size the component. Otherwise it's skipped.
commitProperties
Called after measure.
Applies all property changes (from setting properties on the component) to the component (they were stored in private variables for that first frame).
Called a frame after initial property settings.
This is the most important method to override in my opinion. So for your CoverFlowContainer, say you set the hypothetical distance, gap, selectedItem, and tilt properties. When you set them, store them in private variables. Flex will wait a frame, and call commitProperties. In your overridden commitProperties, you can then say layout.updateEverything(selectedItem, distance, gap, tilt); so to speak. So this is the method you override to make all property changes be applied at once.
updateDisplayList
Called after commitProperties
Called top down.
You only override this to set visible properties on the component, such as setActualSize, graphics, etc. But by now (because of `commitProperties), you have all your required variables to update the display set to the right values.
Overall
So from my experience, I worked a lot with these lifecycle methods when creating a component library for things I would use in a million projects:
TitleWindow (my own version)
View3D (for Away3D/Papervision)
Tree and Stack for Flex 4
TextArea (with prompt, expandable, etc.)
ToolTip (easier to skin tooltip)
I needed to make sure everything was updated and rendered perfectly according to the lifecycle. Reading and understanding the Flex 4 Spark Source Code really helps clarify when to override these methods. As does the Openflux Source Code (very simple, clear alternative to the Flex Framework. Not as feature rich so it shows how to bare-bone override those methods to accomplish some pretty advanced things).
When I develop applications and make things like AdvertismentView, MenuView and LoginView, I don't ever think about it because all the components I'm using have already solved those problems (ViewStack, Group, List, etc.). I'm basically just setting properties they've defined and updated in their own commitProperties override.
The only time I would start overriding lifecycle methods in a View would be when I need to access custom variables from outside the view. So say I had a custom RichTextEditor and I created some properties called showFontControls and showStylePanel. When I set those variables, I would probably do what they described in the Data Binding Presentation: accessor sets private variable and calls the invalidation methods, lifecycle methods execute a frame later and I have overridden commitProperties and updateDisplayList to show those panels and fonts. But in practice, that's probably overkill because it wouldn't offer that much of a performance gain for the amount of work it would take. I'd just set up some binding to a visible property in that case. Nevertheless....
The best thing to do to really get into this is to just download the Flex SDK Source and see what they're doing.
Hope that helps.
Lance
Here's another presentation by Deepa (from the Flex framework team) that goes over a lot of the same framework methods, including a nice explanation of why the whole invalidation model exists to begin with:
http://tv.adobe.com/watch/max-2008-develop/creating-new-components-in-flex-3-by-deepa-subramaniam/
When I try to access the hidden TABs of my tab navigator control in action script, it returns a null error. But it works OK if I just activate the control in the user interface once. Obviously the control is not created until I use it. How do I make all the tabs automatically created by default ?
<mx:TabNavigator creationPolicy="all"/>
That should do it. Deferred instanciation is a feature, but sometimes it is a hassle.
The Flex framework is optimizing creation be default (creationPolicy="auto") so if you have a configuration dialog with a lot of tabs, for example, and the most useful tab is the first one, your application does not spend time and memory initializing the tabs that the user never sees.
This makes a lot of difference when dialogs like this never release, and is a good default to go with.
One thing to look at is using a private variable in your dialog/form instead of pushing the data to the control on the hidden page. This style treats the whole form as if it were a component, which it sort of is. To repeat: the MXML form/dialog/canvas is a class, and it can have data and methods in addition to containing other components.
Cheers
On a side note, I've run into the deferred-loading policy in a multi-state application, and circumvented it by forcing all elements to be included and invisible in the initial state. Something to consider, but only as a hack.
I have an MXML component in a website that I am reusing in a few different screens.
Based on what the user clicks, the component initializes a few values and starts playing media.
Now if I click through the site, and I play media in screen 1, the component initializes fine and plays the media.
If I then go to screen 2 and play the media, the component initializes twice. Once for screen one, and once for screen 2.
When I then go to screen three, it will start initializing three times.. So it is creating a new instance of the MXML component for each screen!!
How can I make sure that the MXML component only initializes for the screen that I need it to initialize for?
What I really want is that this component always has just one instance throughout the whole application. Is it possible to make that MXML component into a Singleton, so that I always have one instance of that MXML in my application?
Can you explain this a little more indepth? What do you mean by "screens"? It sounds like you have your component nested in some sort of view stack, and that your screens are different sections in the view stack, but it's hard to tell here.
Regardless, I think the solution is to abstract the part of your component that you want to be a singleton from the view. Flex initializes objects in view stacks in a lazy manner by default, but this can be overridden using the creationPolicy property on the ViewStack object. It sounds like your creationPolicy is initializing children as you access them, and something in your component code is causing other instances of the same object to re-fire some initialization code when others are created (possibly in your experimenting for an MXML singleton.)
To truly achieve your desired effect, you should probably just write a bit of actionscript that intelligently re-parents the display object you only want to be created twice. The idea of a "singleton" doesn't make as much sense when we're talking about view objects on screens - to have it displayed in many places, you need many instances, and the process of re-parenting is slightly more complicated than the singleton pattern, so you'll need to do a bit of creative logic around that.
Hope this helps - again, please feel free to post some more source code if you want a more specific response.
Why don't you make the component into a module and use it that way. You Load and/or Unload a module and use it where ever you like! in just calling it as a single item! and you have very much less overheads in your application.
I'm building my first Flex custom component, in Flex 3. It is a data table based on the 'Grid' container class, with a simple text Label in each cell. (DataGrid and AdvancedDataGrid were not appropriate starting points for my needs.) The component works quite well using smallish tables, but I tried stress-testing it using a larger table, and have been disappointed by the results.
The component creation process has some slow spots, but those are in my power to optimize and aren't my primary concern. What worry me more are what appear to be limitations in the Flex framework itself.
This 'large' sample table has a bit over 7000 cells in it. This is largish, but still 1-2 orders of magnitude less than the biggest I need to accommodate. In standard Grid structure, the main portion of the component consists of a Grid with 400 GridRows of 16 GridItems each, plus a few other smaller ancillary Grids.
Once the table renders, I find the following:
Mouse-related events are slow to fire. Specifically, I have rollOver/rollOut event handlers registered on each table cell, to let me highlight the cell under the pointer. On a small table, I could move the mouse over the table very quickly, and the highlighting would follow the pointer in real-time. With the larger table, the highlighting is very jerky, changing only about twice per second, skipping over many cells.
If I place the mouse cursor over the component and leave it there, my CPU is pegged (one processor core, anyway), and stays that way until I move off of the component, when it drops to idle. My component isn't doing anything at all at this point.
It feels like Flex simply cannot scale to support component trees that are this large. I shudder to imagine how it would behave with 100,000 cells. Perhaps I'm pushing the Grid beyond its intended use, but having an object per table cell doesn't seem like an unreasonable model, and ~14,000 objects in the tree (a GridItem and a Label per cell) seems pretty modest.
I have yet to get useful data out of the FlexBuilder profiler; I'm working on it. For now, my biggest questions are:
Am I really pushing the limits of Flex with this modest test?
Is my approach to this component completely off-base?
I'm running this on Flash Player 9 under Firefox on WinXP.
Yes, Flex is not designed to support very large numbers of components, it is well known that you should minimize the number of components and don't use features that you don't need (Eg. DisplayObject instead of Canvas if you don't need the extra functions).
It's unwise to mirror your data exactly with displayed objects. DisplayObjects (and related classes) are relatively heavyweight, and you need to control how many of those you have.
I would say that the scale you're working at, with 1000+ Cells, and an event listener for each one, would definitely reach Flex's limits.
I think you should take a better look at your approach and architecture. I assume you are not displaying all 1000+ items at the same time, perhaps you should use paging and display 100ish with each screen, with previous/next buttons to move on to another page. You could also consider dynamically adding and removing rows using a custom scrollbar, simulating the scroll effect. This is much more complicated to do.
Boy, it seems we can write a book on this topic. Or atleast a chapter. We learnt quite a few things in this area as we were developing our products.
Bottom line - yes, Flex will slow down to a halt when you add 1000+ "things" on the screen. Here are a few bullet points, and some repetitions of what's already mentioned (just to be concise)
1) Always draw only what is visible. Hans Muller, the architect on the new Spark DataGrid has a great writeup on ViewPorts. http://hansmuller-flex.blogspot.com/2009/06/introduction-to-viewports-and-scrolling.html. So instantiate enough "cells" to fill up the visible area, and basically recycle them as the user scrolls.
2) Recycle, recycle, recycle: Further to above, as the user scrolls, you obviously have to recycle cells that are now out of view to show the ones that are in view. Here there are a few things we learned the hard way :-)
-> Instead of disposing and creating new cells, either use reparenting or use repositioning (prefer repositioning)
What this means is this: Say you have a 10X10 grid (visible) showing a 100X100 data provider.When the user scrolls to cells 20X20, the quickest way will be to set the X and Y of the existing cells to the new locations, and then call set data for each. We used reparenting earlier because our scenario was a series of related containers, so this may not apply to you. But bottom line - we simply move "rows" around the visible area. So creating and destroying will be slow, removing and adding to the display object list will be faster, and just moving around (x,y) will be fastest.
3) Choose what you inherit from wisely: The Flex SDK is a beast. So choose your "cells" base class wisely. For example, the SDK DataGrids, have a lightweight renderer that inherits from UITextField (Halo), as opposed to Label. Even UIComponent will be heavy in certain scenarios. Look up the asdocs for UIComponent and see if you need everything in there, else consider inheriting from further up its hierarchy.
4) Cache Calculations: Do this last in your development cycle. Once you are done with a feature, run flex profiler. Identify the longest running methods, and the most called methods. We always do this when we release, because there's always improvements to be made. There's a lot of math involved when you're developing a highly visual component, and too many calculations will slow things down.
5) Make sure you profile for memory : Unwired event listeners, rogue object references, etc will kill performance. Flex profiler is an excellent tool to combat this, so make sure you use it.
We have some good links here:
http://www.flexicious.com/resources/Ultimate/Docs/LargeDataset.htm?
Hope this helps!
If you look at any List-based control in the Flex framework, you'll see that they make significant use of item renderers which are recycled. So a DataGrid with 20 rows displayed only creates about 22 renderers and recycles them as you scroll through the list. This is why a DataGrid can hold thousands of records and still have pretty snappy performance. I recommend you check out Peter Ent's series of articles on item renderers and take a look at ListBase/List and some of the related classes to understand how to build something similar:
http://weblogs.macromedia.com/pent/archives/2008/03/itemrenderers_p.html
Without seeing your code and knowing exactly what you're trying to do...it definitely seems like you're pushing the limits of Flex by pushing that much data into the framework all at once.
Keep in mind that the Flash runtime wasn't designed to handle huge applications...but run somewhat light applications inside the browser. It also seems unlikely that your users are going to need to have access to all of those controls all at once.
You could try providing data services (Java, .NET, etc.) to drive the data in your application. You would then page through the data so that the framework is only dealing with maybe 200 - 300+ elements at a time.
In flex, if you using Mouse move event to redraw anything .. You might have experienced very slow rendering .
eg:
this.addEventListener(MouseEvent.MOUSE_MOVE, redraw);
and
public function redraw(anything:Object=null):void{
//draw something here
this.graphics.clear();
this.graphics.lineStyle(3, 0x000000);
this.graphics.moveTo(startPoint.x, startPoint.y);
this.graphics.lineTo(endPoint.x, endPoint.y);
this.scaleTextInput.x = centerPoint.x;
this.scaleTextInput.y = centerPoint.y;
}
The Above code results very slow rendering ...
Solution:
Use Event.ENTER_FRAME event instead? Although more resource intensive than the mouse move event, you should receive considerably more updates per second, allowing the mouse to appear more responsive to the user:
Eg:
this.addEventListener(Event.ENTER_FRAME, redraw); instead of
this.addEventListener(MouseEvent.MOUSE_MOVE, redraw);
and You are good to go ..Happy Flexing
More on:
http://www.deepakdhakal.com