Mailing-List: contact users-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@flex.apache.org
Received-SPF: pass (nike.apache.org: domain of yariv.gilad@gmail.com
 designates 209.85.212.46 as permitted sender)
MIME-Version: 1.0
Sender: yariv.gilad@gmail.com
In-Reply-To: <CE18222D.E38F%aharui@adobe.com>
References: 
 <CAMpOuQs4H7WCkGuTP_H3WA62swfNeW2g2O4JXAnk9mfmR=z=MQ@mail.gmail.com>
	<CE18222D.E38F%aharui@adobe.com>
Date: Sat, 27 Jul 2013 07:26:35 +0300
Message-ID: 
 <CAMpOuQtROskjrpPGLZ-E7jRa8yJ88XM+PrLERm=c1izSsLG+0g@mail.gmail.com>
Subject: Re: non-blocking preloading animation?
From: Ajar <ajar.interactive@gmail.com>
To: users@flex.apache.org
Content-Type: multipart/alternative; boundary=047d7b3a7dd8265cbf04e276aaa4

--047d7b3a7dd8265cbf04e276aaa4
Content-Type: text/plain; charset=ISO-8859-1

Thanks for that Alex.
:)

On Fri, Jul 26, 2013 at 10:58 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
> On 7/26/13 12:31 PM, "Ajar" <ajar.interactive@gmail.com> wrote:
>
> >Hi all
> >I have a big flex web project
> >It takes a while to load.... its around 3M for the main app swf and 80K
> >for
> >additional 4 modules that loads afterwords
> >The loading weight is not bothering me, as we have this tiny animation
> >with
> >gags for the user to go through, it's not terrible.
> >What bothers me is that once the app swf loads, everything chokes and
> >freeze, until the app initializes itself.
> >So I can't go the "perceived performance" way really because whatever I
> >put
> >there freezes and chokes for good 30 seconds...
> >I even tried putting the preloader animation in a separate light-weight
> >flash swf and have it in a separate div on the html on top at the center
> >of
> >the page.
> >it behaves just the same. it doesn't matter if its in a different swf, it
> >chokes just the same...
> >Does workers relevant for this kind of scenario?
> >Is there anything that comes to mind I could do beside re-writing the
> >application?
> Well, it depends on what you mean by 're-write'.  Use the profiler to see
> where all of the time is going.  Some of those application frameworks
> being discussed in the other thread can contribute to the problem by doing
> their injections on creationComplete.
>
> Another app I analyzed was using creationPolicy=all everywhere.  Sure, it
> makes your code easier to write, but then that's the price you pay.  Think
> "on-demand" and "just-in-time", not "just-in-case".
>
> >:)
> >cheers
> >Ajar
>
>

--047d7b3a7dd8265cbf04e276aaa4--