Ability to generate custom build with reduced set of features

[Oza94]

Hello,

I just moved on Pixi.js for my HTML5 game and I love this library!

I wonder if it is possible (or planned) to generate a custom build of pixi to include only the used features (and their dependencies)? My main motivations are :

• I do not use loaders (and other few things) since it is handled by the engine itself
• An HTML5 game can be quite heavy to load, each removed byte is a good thing

In my opinion, since the Pixi is already wrapped in separate "classes" and files, a "partial build" feature should be easy to implement with grunt.

[photonstorm]

Why not just create your own build file to do it? The grunt task is already there, all it would take is 5 mins to customise it.

Just beware that Pixi has a lot of internal dependencies. You can't just remove something at random and expect it to carry on working. However you absolutely can remove the loaders and interaction stuff, and it's easy to remove any/all of the Extras too (as I do so). But that's about as far as you can go, everything else is used.

[jonsquared]

I just released a grunt plugin that may help, especially since you do not use loaders (one of the main reasons for its creation): grunt-file-dependencies
There are some usage examples there for how you might use it to feed into a concat task (and then a minify task).
If you combine it with something like grunt-sails-linker on a watch task, you could test your code un-concatenated for easy debugging and then concat/minify only during a release build.

[bvalosek]

@Oza94 What percentage of your total game payload (images/assets/code/etc) is the PixiJS codebase? I don't see how shaving off some KBs from the engine will matter vs the (probably) MBs of game content.

[Oza94]

Sorry for the late response...

@photonstorm the problem is not only to create a custom Gruntfile, but I also want the build to be integrated with my own project build process (I use gulp and bower). The actual solution I have implemented:

• retrieve the library with bower
• replace the Gruntfile in bower_components\pixi with my custom Gruntfile <- that's the part I want to change
• build Pixi
• build the rest of the project

@bvalosek yes if you include images, ect. the size of pixi is ridiculous. However, the weight of my concatened js file has jumped from 500kb to 710kb when I started using Pixi, and I'm perfectionist, that's the first reason. 😄

The second reason is that I plan to make a mobile version of the game in the near future (which will be a sort of "tamagotchi" of the real game) and in this context, the payload size is much more important.

[photonstorm]

I bet it isn't 700kb down the wire though once gzipped. Most devs seem to
forget this crucial part for some reason.

On Tuesday, December 23, 2014, Oza94 notifications@github.com wrote:

Sorry for the late response...

@photonstorm https://github.com/photonstorm the problem is not only to
create a custom Gruntfile, but I also want the build to be integrated with
my own project build process (I use gulp and bower). The actual solution
I have implemented:

• retrieve the library with bower
• replace the Gruntfile in bower_components\pixi with my custom
  Gruntfile <- that's the part I want to change
• build Pixi
• build the rest of the project

@bvalosek https://github.com/bvalosek yes if you include images, ect.
the size of pixi is ridiculous. However, the weight of my concatened js
file has jumped from 500kb to 710kb when I started using Pixi, and I'm
perfectionist, that's the first reason. [image: 😄]

The second reason is that I plan to make a mobile version of the game in
the near future (which will be a sort of "tamagotchi" of the real game) and
in this context, the payload size is much more important.

—
Reply to this email directly or view it on GitHub
#1283 (comment)
.

Photon Storm Ltd.
http://www.photonstorm.com

Skype: richard.davey
Twitter: @photonstorm

Registered in England and Wales.
Company ID: 8036404
VAT Number: 136 4333 27

[mattdesl]

700kb is pretty huge. Gzip helps down the wire but in this case a big chunk of bottleneck (for mobile) will be in parse/execution time.

http://timkadlec.com/2014/09/js-parse-and-execution-time/

If it were me, I'd just fork Pixi and set up a new grunt file. Then pull from upstream as new patches come in to dev branch.

[photonstorm]

Games are not web sites. They should not be profiled, built or apply metrics in the same way, regardless of the fact that they share the same delivery mechanism. User expectations while waiting for a game to load are vastly different to those encountered while waiting for a web page to load. With a page every byte counts and parsing time before it will even start working is incredibly important. Smaller is always better, but in the grand scheme of things a few extra 100ms waiting for a game js file to parse is mostly irrelevant compared to the rest of the asset load and start-up time. The only time it's an issue is if your site autoloads the game, or it's being used on the home page or similar.

As an aside I can't wait to see web developers start freaking out over the multi megabyte payloads of the Unity WebGL export ;)

[mattdesl]

User expectations while waiting for a game to load are vastly different to those encountered while waiting for a web page to load.

Making mobile users wait several seconds on a white screen (with no response because of blocking script parse/execution) is a pretty terrible UX regardless of whether we are discussing websites or games.

Keep in mind -- with SPAs and browser bundles, a game is often tied to the website that surrounds and delivers it. And, of course, many of us are not using Pixi to just build games. ;) e.g. see the Pixi-powered McDonalds microsites.

[englercj]

You can do this now in v3 by running gulp with a command line switch of what feature to exclude. Features you can exclude currently are:

• extras
• filters
• interaction
• loaders
• spine
• text

For example, if I didn't want spine or extras:

gulp -e extras -e spine

and my output bundle would not include those items.

[serprex]

I tried "gulp -e loaders -e spine -e extras"

While pixi.min.js has reduced those modules, pixi.js still includes them. Ignoring them in the main bundle would be useful for debugging purposes also since it seems best if the behavior of both modules remains the same (ie PIXI.loaders should be {} for both if the build wanted to exclude them)

Also while I've been using the development version for easier debugging on the rare occasions that errors occur in PIXI, it's hard to justify using a 1.7MB development version compared to a 252KB blob

[englercj]

It shouldn't be including them in the main bundle, I didn't see them their when I looked earlier. The reason the dev bundle is so large is not because of our code but because the sourcemap is embedded. The take that out and we will probably be less than 500K.

In fact the min bundle is created by minifying the main bundle, so it doesn't make sense that you have them in one but not the other.

[serprex]

Messed around with things, seems I indeed am unable to use get ignore working. Arguments are being passed to the ignore loop, but browserify doesn't seem to care (also tried setting basedir & ignoring src/module, to no avail)

Browserify version is 2.3.0 I don't know how to use npm, that's my npm version, browserify is 8.1.1

[englercj]

We use browserify v8, sooo you should probably upgrade..

https://github.com/GoodBoyDigital/pixi.js/blob/dev/package.json#L24

[thomfoolery]

I'm trying to build a diet version of PixiJS using the 'dev' branch but no matter what I try to exclude using -e argument the resulting files in the bin folder are always the same size. Is there something I am missing?

[englercj]

Hmm, ignore doesn't seem to be working. not sure whats up. I'll try to look at this soon.

[englercj]

Got this fixed by the way in the latest dev code.

[Friksel]

The issue of modules not being excluded during build in v3 as described by @thomfoolery I'm having at v4.2.2 right now. Perhaps the same issue is back again in v4? : #3322

[PierBover]

For anyone wondering how to do this for v4 you have to edit the dist command in package.json with something like this:

pixify -d dist -n PIXI -o pixi -e accessibility -e extras -e filters -e mesh -e particles -t babelify

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.