I've had to do something very similar in the past. The key is to realize that Flex framework has no way of knowing that a component is completely finished updating. I had a component that loaded x number of images, y number of text labels and z number of vector arts. So, in my component that holds all these sub-components, I had a running count of all the objects that finished updating. Then when I knew that all components were 'done' rendering, I threw a custom event to trigger a bitmap grab.
Almost all the time, the network calls (even if they loaded up from the browser cache) ended up being the longest poles, so I ended up simplifying my logic to check if all the Loader components finished rendering. Hope this helps. Thanks, Om On Tue, Aug 27, 2013 at 11:02 PM, Alex Harui <[email protected]> wrote: > > > 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 > >
