Recently I found out that there are several things that one can do to massivly slowing down a Flex application. One of those things is the use of many nested layout containers. Another thing which is very problematic is the usage of lot's of relative positioning and sizes.
I do understand that there is a very big amount of calculations that must be done before the layout elements can be displayed. What I do not understand is why the rendering is done all the time. With a certain amount of complexity in your layout your CPU usage is 100% all the time even if there are no changes in the layout.
Why is that? And what can I do about that (without redoing the whole layout)?
Thanks a lot!
It is true that nested containers do slow things down, but I haven't yet been able to get the CPU usage up to 100% yet. The framework should only recalculate the layout of a component after its invalidateDisplayList() has been called. Calling this schedules a call to updateDisplayList, in which the layout of a container is calculated. Consequently, the display lists of the component's children are invalidated as well.
Besides doing it yourself, the displayList can be invalidated by the framework for a variety of reasons. For instance, it is always invalidated after invalidateProperties(). It could be that you have something that accidentally invalidates the display list of some high-level container all the time, thus propagating it down to its children.
Do you have any code to share? And what kind of a system are you running?
Any other solution other then refactoring your layout and not use many nested elements means change the way adobe framework works, and you do not want to do it !
My suggestion although might be painfull , change your view components , use absolute size and location where possible , do not nest too many elements .
The reason for the bottle neck with nested components is that the invalidate functions go 2 way , first up the tree from the changed component to the root , then from the root to all its nested elements , that whats taking your cpu .
Finally I found out what exactly the problem with our application was!
The problem was not that we used lot's of nested layout containers. I found out that there was a third party component that we use which attaches an event listener to the ENTER_FRAME-Event. Unfortunately this component does not shutdown properly so the event listener never gets removed. One thing this event triggers is a call to invalidateDisplayList(). I found out that the ENTER_FRAME-Event occurs very often (I still don't know why exactly this happens) and because of that the whole layout is recalculated over and over again. Because of the nested structure of our layouts this is a very time consuming thing to do and therefore the CPU gets very busy!
I could solve this problem by adding some extra code to the component that properly removes the event-listeners if they are no longer needed. The result of that has been that the application now does not need any CPU-power when in idle-mode. Hooray!!
Related
What I want to Achive:
Toggling the appearance of an Item, where the components that describe the appearance are loaded dynamically, but common elements are not loaded multiple times.
Lets say, I have a list of elements with an icon (e.g. cover) and a title (e.g. music title).
When clicked/dragged, it shifts the shape, so additional information can be displayed (e.g. duration, artist, ...).
Finally I have a DropArea, in which I can drop those elements. Here I only want to display the icon.
As I am informed correctly, it is not advisable to have all three forms pre-loaded and only shift the visibility and other parameters of the additional objects, as the first list is a ListView.
Therefore I decided, to create multiple components, and then load them with a Loader.
On the other hand, this leads to some overhead, for I load and unload the Icon, that is common to all the components, each time, the shape shifts.
My solution so far is, to load the image outside of the components, re-parenting it each time, the shape shifts. This however feels odd, and I am not sure, if this might not be the less performing way, compared to the "loading everything at once and resetting visiblity and positioners"-approach
What is the proper way to do this?
For the efficiency aspect, the most performing one should be that only dynamically loads something that is really dynamic, and leaves other things static(or so called declarative). In your app, the icon should be declarative, I think.
Regarding with reparenting, actually re-parenting is quite common in Qt Quick programming, especially within dynamically loading context. The parent in Qt Quick is not the same concept of QObject. It's just visual management (not memory management). That's why you can see Qt Quick even provides ParentChange in State/Transition.
I am looking for some advice in regards to getting a very quick display of our reports. The problem I am working with is I receive an XML data structure that defines our layout. The report can be anywhere from 2 to 3 pages to perhaps 20 to 30. So to make the report display as quickly as possible I would like to just render the visible portion of the report. Here are the issues I need to overcome to accomplish this and I am looking for some advice how how to accomplish this.
To get a better visualization, Think of this like a word document. The reports have sections and I want to be able to get them to display as quickly as possible.
1) Of course I do not know the height of the child components I will be adding. Is there any techniques where I can determine if the components I am adding are not include in the view port and could I trigger off scroll bar movement.
2) I was thinking of adding estimation to the children components and then using that to set the height of the parent container. then when I receive scroll bar move event, I would check if the child components have been added to the parent and if not add them. Is there anyway to get the height of a component without rendering it?
3) Does Flex support anything built in that will accomplish this.
Any other techniques would be welcome. Basically I want to get the report displayed to the user as quickly as possible and delay the rendering of components that are off the screen.
Any suggestions would be welcomed. Thanks in advance.
Added Info.
Hard to provide code since I have not coded it yet. Let me try and expand with some details. I have a Parent Container where I take the some XML and using the XML creating children components based on the information in the XML. Right now when we do this it can take a long time to render a long report. What I want to do is to reduce the rendering time by delaying the rendering of those children objects. I have looked into things like the creation policy and createDeferredContent, but not sure if this is the right way to go. Guess the general problem I need to attack is how to do you stop rendering objects once you are outside the parents viewport. What I want is an item renderer like functionality but there is no similarity between the children. Perhaps a picture might be useful (will add as soon as I get to 10 points)?
Use spark List with useVirtualLayout turned on. This is what it does.
There is always similarity between children, but if you can't find it, you can use an itemRendererFunction.
I have a Spark list with a customItemRenderer that is taking a good 3 seconds to initialize with just 50 items.
I'm using Flex 4.5, my ItemRenderer is already very optimized, using as little nesting as possible, fxg and so on.
Is anyone having similar issues?
I've tried almost everything in the book bar going back to mx.
So the issue was due to the way that spark handles styling the issue is detailed here: http://bugs.adobe.com/jira/browse/SDK-29880 and can be sorted by monkey patching with: http://taytay.com/?p=169
Also removing global css selectors "*" helps.
Avoid HGroup and VGroup as much as possible, use absolute layout instead. I've had this same problem at that's fixed most of it for me.
1 hgroup + 1vgroup each three times = 6 automatic layouts PER ITEM. So in total you have 150 objects, WAY too much.
After applying the monkey patch mentioned by Pedro with only modest performance gains (I suppose we had fewer styles, or the performance was fixed in a more recent patch), I continued profiling the initialization of our List instances.
One thing I found is that Flex spends quite a lot of time in UIComponent's initializeAccessibility function, even though our application does not support accessibility in any way (whether applications ought to do that is an entirely different issue).
Merely adding -accessible=false to the compiler arguments cut time spent initializing a particularly heavy list by about a third! Not only that, the whole application in general feels snappier when windows are opened, controls are shown for the first time, etc. If you have no need of accessibility support, you might want to check this out - if you do, I'm sure something can be done to fix the abysmal performance of initializeAccessibility - simply through overriding it in your component implementations, or through even more monkey patching :-)
Are your item renderers checkboxes by any chance? A few folks have recently run into a bunch of performance issues with Spark in general.
http://blogs.adobe.com/aharui/2011/04/migratory-foul-performance-problems-migrating-from-flex-3-x-to-flex-4-x.html
Adobe has been notified, and apparently are working on it:
https://bugs.adobe.com/jira/browse/SDK-29451
So, I have an application where I'll be loading any number of swfs into a SWFLoader and removing them at runtime. The issue is - they are all timeline based movies authored in Flash CS3. I have very little control over what is in the movie other than the authors are not able to program any interactivity (i.e. no event listeners) but I want to make sure I am using the best technique to stop and trash these things so they don't hang around in memory too long. Here is the process I use right now to get rid of them:
Try stopping the content using MovieClip(content).stop();
Remove any listeners that I know about (ENTER_FRAME, etc...)
Set the source of the SWFLoader to null.
cross fingers, pray, make sacrifice (human if need be)
So that seems to work but is some better (or more comprehensive) method that you guys use to accomplish this same task? In all honesty - I'm not entirely sure these things aren't just kept in memory but I don't hear them so I don't know that they are there...
That's pretty much right. Loader (what SWFLoader uses under the hood), removes it's loaded clip from the stage with .unload(), but depending on what the clip has referenced the clip still runs and events still fire.
Flash Player 10 added .unloadAndStop(), but that is mostly just doing the same thing you are.
You could also try giving an explicit SecurityDomain (and probably ApplicationDomain so any contained classes are separate as well) in the optional LoaderContext parameter to Loader.load(), to try to prevent it adding event listeners outside (if you don't trust the clip not to), and avoid forming any references to anything from the clip so it can be garbage collected — but apparently it might still not unload in some cases.
In our application (a game), in some cases it can't run fast enough. Obviously we'd like to speed it up, but in the mean-time when this happens it causes many problems (or if it's not causing them, the two are related).
The one which is least related to our own functionality is that the built in Alert.show() method stops working. Typically the full-screen transparent box appears but not the actual popup. I believe this is down to Flex giving all available cycles to other tasks... but it's proving difficult to investigate analytically so I am happy to hear another explanation.
To clarify, core parts of Flex are simply not working in this situation. I've stepped through the code for instance where a new element is added to the screen, everything happens and the addChild() method is called on the main display canvas... but then the element does not appear. If we then disable our update loop, the element suddenly appears.
So whether Flex is supposed to run the exact same code or not, somehow it IS blocking is some strange way. As I said, even the Flex Alert.show() method doesn't work.
All Flash content is executed frame-by-frame - Flash executes one frame's worth of code, then updates the screen, and then waits until the next frame update.
When Flash can't keep up with the specified framerate, all that happens is that instead of waiting between frame updates, Flash does them as fast as it can with no waiting in between. So the only visible difference is that frame updates occur less frequently. There are never cases where code is skipped, events are dropped, or screen redraws are skipped for performance reasons (unless you've found new bugs).
So the most likely culprit is that either you have a problem with code that's very time-dependent (such as code that expects two timers to trigger on the same frame), or some other problem that's being misdiagnosed. (For example, maybe there's a bug causing a slowdown, rather than a slowdown causing your bug.)
I'm not too sure if Flex has some additional performance handling of it's own. But for pure actionscript the only thing that would happen is the framerate would slow to a crawl, everything will happen normally just slower. If you stack very large amounts of transparent or masked objects you might get some weird behavior, but that should be more noticable.
And I guess telling you that making a game in Flex isn't that much of a good idea (just because of the performance overhead the framework has) is a bit late ;)
I like to make games in FLEX 3 (actionscript3), its actually pretty handy solution when compared to Flash CS3: good debugging environment without hassle.
Of course it depends on the game style which one is better, if you need lot of graphics you may like Flash more, but Flex allows you to use external images, components, etc. Notice I am not talking about Flex XML project here.
Answer to your performance issue: You can use e.g. old MacOSX machine to see what happens in a very slow machine, a few solutions are:
- move objects more than x++ y++ pixels when machine is old
- reduce objects
you can detect with a timer how slow machine is..