flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Bitmap Caching and Multiple Partial Updates
Date Wed, 28 Aug 2013 09:02:36 GMT
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 <aharui@adobe.com> wrote:

>
>
> On 8/27/13 1:41 PM, "Taylor Bastien" <taylor.bastien@4point.com> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message