Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CACK5iZfaTj3W+040sdUn4b9vna+zjfd0S52dqygGzhEA-AQ3Xg@mail.gmail.com>
References: <1453350582475-51348.post@n4.nabble.com>
 <CACK5iZexYzZKibGFCv2oHKQFXVheCCmwCNLrU+OiSj3SdtmooA@mail.gmail.com>
 <CAO4dzBfzgDUoG=nt_1rmcJpX0S0s_Y7k037o2kfjhfXxi1qL8w@mail.gmail.com>
 <1453370641581-51351.post@n4.nabble.com>
 <1453370785839-51352.post@n4.nabble.com>
 <CAO4dzBdwMkzqhiy1ZsgtTqqisW8TeLBBo4EMPvCkAKO8_fn6Qw@mail.gmail.com>
 <CAO4dzBcunVSBM9HH97D6Tm4n8dinvmAyEWaLsKuGp1akWHev8Q@mail.gmail.com>
 <D2C642DA.6168A%aharui@adobe.com>
 <CAO4dzBc5r3_Y1sfqKN_UfiEV1HBcnPzbK_oLbeN8KCbfFJLBTg@mail.gmail.com>
 <D2C64A2A.616A1%aharui@adobe.com>
 <CACK5iZfaTj3W+040sdUn4b9vna+zjfd0S52dqygGzhEA-AQ3Xg@mail.gmail.com>
From: jude <flexcapacitor@gmail.com>
Date: Thu, 21 Jan 2016 22:32:46 -0800
Message-ID: 
 <CANcBHECAYKZZFou7_8Zmfb5XTCZj4k246kUPtbHeNyeRiOkoJg@mail.gmail.com>
Subject: Re: flexjs game hugryhero
To: dev <dev@flex.apache.org>
Content-Type: multipart/alternative; boundary=089e0160c42ceccd6e0529e66486

--089e0160c42ceccd6e0529e66486
Content-Type: text/plain; charset=UTF-8

Even if the initial download size is bigger it can actually load faster.
This is because:

*Fetching resources over the network is both slow and expensive: the
download may require multiple roundtrips between the client and server,
which delays processing and may block rendering of page content, and also
incurs data costs for the visitor. [1]*

So using data uri's can get you a faster TOF (time of flight) page render.
Not sure if I'm using that right but it sounds cool. The downside is that
if you reload the page nothing is in the cache. But then again, if you plan
it right you should only be downloading the changed content (a small JSON
object).

I'm using data URI's in a few places and for small graphics like lines and
boxes and it's only a few lines of content. The reason I'm doing this is to
translate an SVG graphic into something older browsers can render, for
example, the webkit in AIR does not render SVG (in my tests) so converting
those to data URI allows the page to render as expected.

Google has some good info but the information shouldn't be taken as gospel.
They are still catching up to things we are used to. For example, Angular
JS is being rewritten from the ground up.
 [1]
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching

On Thu, Jan 21, 2016 at 8:53 AM, OmPrakash Muppirala <bigosmallm@gmail.com>
wrote:

> Any reason we want to embed images?  It makes sense in a swf because it is
> a compact file format.
>
> For the HTML version if we stick a big base 64 image in the minified code,
> we are unnecessarily making the initial download size bigger.
>
> A better approach would be to use spritesheets when dealing with image
> data.   These spritesheets should be downloaded on demand like all other
> assets.
>
> Thanks,
> Om
> On Jan 21, 2016 8:43 AM, "Alex Harui" <aharui@adobe.com> wrote:
>
> >
> >
> > On 1/21/16, 8:24 AM, "Michael Schmalle" <teotigraphixllc@gmail.com>
> wrote:
> >
> > >If/when you have time, could you make a JIRA that sort of outlined the
> > >process for the base64 encoding? I am good at somethings but something
> > >like
> > >this I really don't have any experience, I know the hooks in the
> compiler
> > >and such but what would actually be involved in getting the bytes to
> emit
> > >out.
> >
> > I would have to do research as well.  Maybe Josh can provide more detail.
> > My concern is, if overused, embeds could make the html file really huge.
> >
> > -Alex
> >
> >
>

--089e0160c42ceccd6e0529e66486--