Sample .js output size -- each sample includes (all fonts?) in res/, embedded

[jcward]

The base3d.js (https://heaps.io/samples/base3D/base3D.js) seems to have too many assets embedded. This is bad when evaluating it strictly from an "app size" perspective (see conversation: https://twitter.com/Jeff__Ward/status/1181296091834155008)

@elsassph suggested maybe it's embedding the entire res/ directory, but I don't see ray.jpg. Maybe it's just embedding too many fonts? I see the SampleApp base class has something to do with fonts -- maybe sharing a base class is a culprit?

In any case, it might be nice to slim down the .js samples as much as possible. Perhaps best would be to not embed (use BinaryLoader.)

[ncannasse]

I wanted the samples to be self-contained, and easy to deploy by default, especially since res directory is common to several samples and is in a parent directory. The resource loading and management is entirely customizable.

[elsassph]

Oh in fact yes the Base 3d sample has a bit of text so I guess the embed macro can't guess which font exactly is needed?

[ncannasse]

By default we embed all res directory. Since resources might be loaded dynamically (for instance a texture referenced by a model file)

Le mar. 8 oct. 2019 à 10:41, Philippe notifications@github.com a écrit :

Oh in fact yes the Base 3d sample has a bit of text so I guess the embed macro can't guess which font exactly is needed?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/HeapsIO/heaps/issues/681?email_source=notifications&email_token=AAHZXQHIWYC74BAXJ2MZCL3QNRBSJA5CNFSM4I6JJ3VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEATMX5A#issuecomment-539413492, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHZXQGA5SSN3S6UUTJZ3MTQNRBSJANCNFSM4I6JJ3VA .

[Yanrishatum]

I have to add, that using Embed FS for JS is bad idea for anything serious in general. Recommended solution would be using Pak FS or custom FS that preloads data beforehand (I use my own ManifestFS for JS). You can still use it to ensure minimum amount of assets present right when app is ready to start loading to show some graphics (something like first frame in flash games that contained preloader interface while the rest of swf was loaded). Maybe rseource management docs should note that somehow?

[lbergman]

I also like how it is now where one can embed preloader graphics in res, and handle the rest with a custom loader. In our case we have a quite complex system handing localization, game variants and game branding which would be unnecessary for most users.

Parsing your loaded data is quite easy with help of the resource system, but for example I remember getting stuck on how to load and parse an atlas dynamically and ended up writing a virtual file system class. So examples with dynamic loading of various kinds of resources would be very helpful.

[jcward]

I also like how it is now...

Oh, no, I'm not suggesting a change to the APIs. But when people look at the web samples, filesize is a primary concern. "How small is the Hello World" indicates the baseline size of the framework. But when the Base2D an Base3D projects embed their resources, it gives a false impression that the framework is larger than it is. An instant red flag for potential web users.

I wanted the samples to be self-contained, and easy to deploy by default.

That makes sense. Perhaps a new sample, e.g. WebLoader, would be to showcase BinaryLoader (or pak / etc), as well as the minimal size of the framework (with nothing embedded). It would be expected that, for this sample, it does not use the res directory. I'll see if I can find time for a PR.