- Updating documentation for clarity, esp. wrt the now / elapsed /
physicsTime.
- Marked elapsedMS as deprecated as it is just elapsed based on Date.now
instead of the high-res timer; both provide roughly equivalent behavior,
with elapsedMS just falling back to worse-case behavior.
There are a fair amount of Signal objects created. In the current
implementation these are somewhat "fat" objects for two reasons:
- A closure / ad-hoc `dispatch` is created for each new Signal - this
increases the retained size by 138+ bytes/Signal in Chrome.
- There are a number of instance variables that never change from their
default value, and the bindings array is always created, even if never
used.
This change "lightens" the Signals such that there is significantly less
penalty for having many (unusued) signals.
As an example of how much this _does_ play a role, in the "Random Sprite"
demo ~2000 Signals are created, with only 12 of these signals being
subscribed to. This results in a shallow size of ~300K and a retained size
of ~600K (which is almost as much memory as required by the
Sprites/Sprites themselves!) for .. nothing.
With these changes the shallow and retained sizes are less than 50K each -
and this is with only ~200 sprites!
This change addresses these issues by
- Changing it so there is _no_ `dispatch` closure created. This is a
_breaking change_ (although there is no usage of such in core where it
breaks); the code referenced "#24", but no such issue could be found on
github.
In the rare case that code needs to obtain a dispatch-closure, the
`boundDispatch` property can be used to trivially obtain a (cached)
closure.
- The properties and default values are moved into the prototype; and the
`_bindings` array creation is deferred. This change, coupled with the
removal of the automatic closure, results in a very lightweight
~24bytes/object (in Chrome) for unbound signals.
This is minor breaking change, as per the removal of the automatic
closure; but no such need/usage was found in the core. (There may be cases
in the examples, which were not checked.)
If merely opting for the array creation delay and keeping the default
properties in the prototype the shallow size is still halved; less
significant but still a consideration.
This de-optimization occurred between 2.0.7 and 2.1.0 and is currently
present through dev.
`Group.forEach`, which is used by QuadTree, had an extreme de-optimization
in assigning to `arguments` - _CPU profiling showed as much as 50% of the
time was used by Group.forEach_ (after the correction it is not
registered) due to this de-optimization making the "When Particles
Collide" demo run with an unsatisfactory performance, even on a Desktop.
The fix uses a separate array and push (which is optimizable; the previous
implementation was not optimizable in Chrome, FF, or IE!).
This also fixes usages of `slice(arguments,..); ushift` elsewhere in
Group, using the same convention. It applies the same update for `iterate`
as does https://github.com/photonstorm/phaser/pull/1353 so it can also
accept null/undefined for `args` from the invoking functions.
- Cleaned up abnormal case handling
- Disabled parallel loading by default; it can be enabled with
`enableParallel`.
- Minor quibbles
- Removed unused `dataLoadError`
Loaded/loading assets are skipped if they have been superceded. This makes
the behavior consistent with respect to `addToFileList`, if the queue is
inspected or modified while loading.
- Added `withSyncPoint` and `addSyncPoint` methods to allow explicit
adding of synchronization points (synchronization points are explained
in `withSyncPoint`.
- Changed the file/asset `sync` attribute to `syncPoint` to reflect
terminology.
Update iterate documentation to cover usage of `args` and added a guard so
that the callback can be used without requiring that `args` is specified.
Ref. https://github.com/photonstorm/phaser/issues/1352
Employee the use of image.complete and a width/height check to detect when
it is available "from cache" and skip having to run though the
onload/onerror cases.
Parallel loading is now supported, configured by
`loader.concurrentRequestCount`. Each file (a pack is now considered a
type of file) asset can be marked with `sync`, which is done for both pack
files and script files.
When a `sync` asset is encountered it must be loaded before any previous
resource any following resource is loaded (but it doesn't have to wait for
previous resources). Pack files are an exception in that they can download
(but are not processed) and they can fetch-around other `sync` assets.
Because of the concurrent nature there is no guarantee of the order in
which the individual events will file in relation to eachother, but local
ordering (e.g. onFileError always before onFileComplete) and overall
ordering (e.g. onLoadStart .. onFile? .. onLoadComplete) is preserved.
There is also increased error hardening and a few previous edge-cases
fixed (and likely a few bugs added).
