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
Related
With custom controls and more complex GUIs, one usually ends up with a bunch of nested panes. Esp. with SceneBuilder its very easy to put together such a design. Are there any performance implications I should be aware of associated with this approach esp when some of these controls will be used in a TableView with a lot of rows (~1000) and lots of updates?
From my days working in Adobe Flex, this approach was frowned upon and could lead to sluggish GUIs.
No, there aren't. Java FX is better than Swing in that regard.
However, the first thing you should do - if you have concerns like that - is to invest a few hours and create a simple prototype. JavaFX is perfect for RAD. Then you'll see. Nobody can possibly guess what your goal is when you say "TableView with a lot of rows (~1000) and lots of updates".
Even though it is not a problem usually, it always makes sense to optimize your UI.
Proper use of JavaFX layout panes helps. Specifically, take a look at GridPane.
I've just found out about View States in Flex (v3.0), but I am not really sure how widely this is used in real-world applications. Is it a good practice to use it? Are there any pitfalls such as maintainability for instance?
I also used states in an enterprise-level app. But very lightly.
States can be really useful to clean up your code for some cases. There is a performance down side, if a state adds a child, the child will not be removed from the list until you go back to that state and and add a new child.
I think states can be useful if you need to enable/disable make visible/invisible a bunch of components back and forth (depending on a state). This is the ideal use-case of states in Flex.
I've used states heavily and find them a far more elegant solution that lots of conditional code. Indeed, I initially avoided them for some of the reasons given above, but after the app became very complex, with multiple variant "states" I realized that I was fighting the framework.
Frankly, I'd make the same observation about bindings. If you don't understand some of the subtleties, they can be your undoing, it's true. However, writing your own code to achieve the same thing seems like duplication of effort. Take a look at the generated code sometime and also read some of the good deep-dives on bindings out there.
I started using states in my app (enterprise-level application) in various places, and have since refactored them all out. Most of my MXML has been replaced by pure AS3 components, and I'm skeptical of binding and the flex component lifecycle. There's a lot of convenience tricks advertised in the Flex framework that begin to feel cumbersome and slow once you really start using them.
Like anything, your own mileage will vary. They might be useful if you can avoid the "everything is a nail" syndrome. Maybe I couldn't.
My Flex web application is almost ready for launch. I'm currently optimizing as much as I can in order to make sure even low-end clients are able to run it fluently. The problem is, I have no idea where to optimize more than I've already optimized.
My question is, what are the usuals suspects regarding bottlenecks? What tips and experiences do you have when it comes to Optimizing a Flex app?
There are some web tutorials on this, this presentation looks helpful. And of course, the Flex profiler could help you identifying the bottlenecks.
That's a good presentation covering a lot of pitfalls. Another thing I can think of is over-usage of bindings in large applications. They're easy to create and forget, silently generating a lot extra code running in the background, and are especially potent when used carelessly on entire classes.
These are some of the things I've seen that cause slow downs. I've only worked with one or two Flex developers, so I don't know if this is obvious, or helpful. Either way:
Transparency: Whenever views have a lot of components with non-opaque transparency (i.e. alpha less than 1.0), these views tend to be extremely slow, especially on older machines.
Object Creation: It seems that whenever there is a lot of object creation happening, the app slows to a crawl, even on newer machines. I worked on an app that created at least a few hundred objects when the application started.
Data Fetching: Whenever data is loaded asynchronously, the app will take a performance hit depending on how much is loaded
Lots of objects: When views have lots of objects in them, they tend to lag and generally drag ass.
Those are the ones I remember the best, having not worked on a major Flex app in over a year.
Other than performance improvements you can optimize the file size of flex applications.That will definately improve user experience.I hope this article helps:
http://askmeflash.com/article/9/optimize-flex-swf-filesize-performance-loading
I'm having trouble finding any resource for adding ctrl-z undo capability to a Flex RichTextEditor control (a lack it apparently shares with other Flex text controls). I'm baffled that it's not in the native forms because it's such a fundamental capability, available in even standard browser text controls I believe.
Any mention of this issue on the Flex sites (there are several) conflict; one says the issue is "Closed" and the resolution is "External" (whatever that means).
Does anyone have any insight to offer? I've got an app the heavily requires extensive text editing. Flex in general works nicely, but this trivial lack is just about fatal, as anyone would imagine.
An example using the Flight Framework to easily implement undo/redo can be found here: http://www.xtyler.com/code/163
I've read elsewhere -- in fact, in the answers to one of my questions on SO -- that the issue is not going to be resolved in Flex 3. Which seems to be correct since we are in 3.2 or maybe even beyond that, and there's no undo in sight.
I was brave/stupid enough to implement an undo-redo in this component myself. At that time I was working on Windows. Now I'm on OSX and I realize just how non-cross-platform my solution is. The very statement of the problem (adding ctrl-z undo capability) is a large part of the problem (OSX has control AND this Apple key thing). Now I have to check how much work it would be to make the thing cross-platform... could be trivial.
By amazing coincidence, just today I've been thinking about NOT using the RichTextEditor but rather something external (FckEditor comes to mind) because the RTE leaves so much to be desired (hence I arrived at your question). I've worked with the RTE a ton and gotten it to do a lot of what I want, but I still wonder why they didn't "finish" this component...
Flex 3 controls do not natively support undo/redo. Here are a couple of libraries that may be of interest to you:
flexundoredo
as3undohistory
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..