On 8/27/13 1:41 PM, "Taylor Bastien" <[email protected]> wrote:
> >Some questions: > >- Is it even possible for: > >1) Flex to make partial draws of a component during a single >invalidation cycle? Well, if you are in startup phase, or creating a new navigator content, or a few other situations, then phased instantiation is turned on. That means that the LayoutManager only processes either commitProperties, or measure, or updateDisplayList. And sometimes it has to go back and run commitProperties again after measure, before updateDisplayList. But eventually, it will finish validating a particular instance and all of its children and dispatch an updateComplete for that child. > >2) An updateComplete to be dispatched before the component has been >fully drawn? For the most part, no. But the moment after updateComplete fires, some other code can modify the display list, or cause the display list to be modified later. For example, if you call the server for data on creationComplete and it takes a second to respond, updateCompletes from the UI widgets will fire, then fire again as data is shoved into them, but if you took your picture on the first one, then there won't be any data in the picture. There is at least one exception to the rule as well, where mx:TextArea fixes up its scrollbar after updateComplete. And some App frameworks like Parsley do work on creationComplete which can cause components to not reach a stable state until another pass through validation. > >- If not, then my code must somehow be triggering the partial >draws. Any tips on stopping this from happening? Nothing comes to mind but maybe if you post an actual and expected bitmap it might trigger something in my brain. I would examine the display list before you capture the bitmap to see if it matches your expectations in terms of number and placement of widgets, and check the invalidate* properties on the children to see if they are still dirty. > >- If I can't rely on updateComplete, is there a guaranteed way >to know that a component has been fully drawn to screen (or that it's at >least in a state from which I can grab a valid BitmapData)? I think you have to prove that all children are also complete and none of them have invalidation* properties set. And then there's that mx:TextArea thing... IMO, performance is best when you only have widgets for things you can see on the screen. The effort to virtualize and pool objects that aren't on screen is usually worth it. -Alex
