2013-10-01 12:54:29 +00:00
|
|
|
/**
|
2014-09-16 16:35:08 +00:00
|
|
|
* @author Miller Medeiros http://millermedeiros.github.com/js-signals/
|
2013-10-01 12:54:29 +00:00
|
|
|
* @author Richard Davey <rich@photonstorm.com>
|
2016-04-04 21:15:01 +00:00
|
|
|
* @copyright 2016 Photon Storm Ltd.
|
2013-10-01 12:54:29 +00:00
|
|
|
* @license {@link https://github.com/photonstorm/phaser/blob/master/license.txt|MIT License}
|
|
|
|
*/
|
|
|
|
|
2013-08-28 06:02:55 +00:00
|
|
|
/**
|
2014-09-16 16:35:08 +00:00
|
|
|
* Object that represents a binding between a Signal and a listener function.
|
2014-07-02 14:25:07 +00:00
|
|
|
* This is an internal constructor and shouldn't be created directly.
|
2013-11-28 15:57:09 +00:00
|
|
|
* Inspired by Joa Ebert AS3 SignalBinding and Robert Penner's Slot classes.
|
2014-09-16 16:35:08 +00:00
|
|
|
*
|
|
|
|
* @class Phaser.SignalBinding
|
2013-08-28 06:02:55 +00:00
|
|
|
* @constructor
|
2013-11-28 15:57:09 +00:00
|
|
|
* @param {Phaser.Signal} signal - Reference to Signal object that listener is currently bound to.
|
2013-10-01 12:54:29 +00:00
|
|
|
* @param {function} listener - Handler function bound to the signal.
|
2013-10-01 15:39:39 +00:00
|
|
|
* @param {boolean} isOnce - If binding should be executed just once.
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
* @param {object} [listenerContext=null] - Context on which listener will be executed (object that should represent the `this` variable inside listener function).
|
2013-10-01 12:54:29 +00:00
|
|
|
* @param {number} [priority] - The priority level of the event listener. (default = 0).
|
2015-07-09 20:15:00 +00:00
|
|
|
* @param {...any} [args=(none)] - Additional arguments to pass to the callback (listener) function. They will be appended after any arguments usually dispatched.
|
2013-08-28 06:02:55 +00:00
|
|
|
*/
|
2015-07-09 20:15:00 +00:00
|
|
|
Phaser.SignalBinding = function (signal, listener, isOnce, listenerContext, priority, args) {
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
2013-11-25 03:13:04 +00:00
|
|
|
* @property {Phaser.Game} _listener - Handler function bound to the signal.
|
|
|
|
* @private
|
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
this._listener = listener;
|
|
|
|
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
if (isOnce)
|
|
|
|
{
|
|
|
|
this._isOnce = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (listenerContext != null) /* not null/undefined */
|
|
|
|
{
|
|
|
|
this.context = listenerContext;
|
|
|
|
}
|
|
|
|
|
2013-08-28 06:02:55 +00:00
|
|
|
/**
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
* @property {Phaser.Signal} _signal - Reference to Signal object that listener is currently bound to.
|
2013-11-25 03:13:04 +00:00
|
|
|
* @private
|
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
this._signal = signal;
|
|
|
|
|
|
|
|
if (priority)
|
|
|
|
{
|
|
|
|
this._priority = priority;
|
|
|
|
}
|
|
|
|
|
2015-07-09 20:15:00 +00:00
|
|
|
if (args && args.length)
|
|
|
|
{
|
|
|
|
this._args = args;
|
|
|
|
}
|
|
|
|
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
Phaser.SignalBinding.prototype = {
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
* @property {?object} context - Context on which listener will be executed (object that should represent the `this` variable inside listener function).
|
2013-11-25 03:13:04 +00:00
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
context: null,
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
* @property {boolean} _isOnce - If binding should be executed just once.
|
2013-11-25 03:13:04 +00:00
|
|
|
* @private
|
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
_isOnce: false,
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
2013-11-25 03:13:04 +00:00
|
|
|
* @property {number} _priority - Listener priority.
|
|
|
|
* @private
|
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
_priority: 0,
|
2013-08-28 06:02:55 +00:00
|
|
|
|
2015-07-09 20:15:00 +00:00
|
|
|
/**
|
|
|
|
* @property {array} _args - Listener arguments.
|
|
|
|
* @private
|
|
|
|
*/
|
|
|
|
_args: null,
|
|
|
|
|
2014-10-28 01:48:24 +00:00
|
|
|
/**
|
|
|
|
* @property {number} callCount - The number of times the handler function has been called.
|
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
callCount: 0,
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
2013-10-01 12:54:29 +00:00
|
|
|
* If binding is active and should be executed.
|
2013-10-01 15:39:39 +00:00
|
|
|
* @property {boolean} active
|
2013-10-01 12:54:29 +00:00
|
|
|
* @default
|
2013-11-25 03:13:04 +00:00
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
active: true,
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
2013-10-01 12:54:29 +00:00
|
|
|
* Default parameters passed to listener during `Signal.dispatch` and `SignalBinding.execute` (curried parameters).
|
2014-03-23 07:59:28 +00:00
|
|
|
* @property {array|null} params
|
|
|
|
* @default
|
2013-10-01 12:54:29 +00:00
|
|
|
*/
|
Signal - memory optimization / reductions
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.
2014-11-24 12:37:24 +00:00
|
|
|
params: null,
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
/**
|
2013-10-01 12:54:29 +00:00
|
|
|
* Call listener passing arbitrary parameters.
|
2013-11-28 15:57:09 +00:00
|
|
|
* If binding was added using `Signal.addOnce()` it will be automatically removed from signal dispatch queue, this method is used internally for the signal dispatch.
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#execute
|
2014-11-30 11:10:52 +00:00
|
|
|
* @param {any[]} [paramsArr] - Array of parameters that should be passed to the listener.
|
2013-11-28 15:57:09 +00:00
|
|
|
* @return {any} Value returned by the listener.
|
2013-10-01 12:54:29 +00:00
|
|
|
*/
|
2014-03-23 08:29:04 +00:00
|
|
|
execute: function(paramsArr) {
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
var handlerReturn, params;
|
|
|
|
|
|
|
|
if (this.active && !!this._listener)
|
|
|
|
{
|
2014-03-23 08:29:04 +00:00
|
|
|
params = this.params ? this.params.concat(paramsArr) : paramsArr;
|
2015-07-09 20:15:00 +00:00
|
|
|
|
|
|
|
if (this._args)
|
|
|
|
{
|
|
|
|
params = params.concat(this._args);
|
|
|
|
}
|
|
|
|
|
2013-08-28 06:02:55 +00:00
|
|
|
handlerReturn = this._listener.apply(this.context, params);
|
2015-07-09 20:15:00 +00:00
|
|
|
|
2014-10-28 01:48:24 +00:00
|
|
|
this.callCount++;
|
2013-08-28 06:02:55 +00:00
|
|
|
|
|
|
|
if (this._isOnce)
|
|
|
|
{
|
|
|
|
this.detach();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return handlerReturn;
|
|
|
|
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-01 12:54:29 +00:00
|
|
|
* Detach binding from signal.
|
2013-11-28 15:57:09 +00:00
|
|
|
* alias to: @see mySignal.remove(myBinding.getListener());
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#detach
|
2013-10-01 12:54:29 +00:00
|
|
|
* @return {function|null} Handler function bound to the signal or `null` if binding was previously detached.
|
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
detach: function () {
|
|
|
|
return this.isBound() ? this._signal.remove(this._listener, this.context) : null;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#isBound
|
2013-10-01 15:39:39 +00:00
|
|
|
* @return {boolean} True if binding is still bound to the signal and has a listener.
|
2013-10-01 12:54:29 +00:00
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
isBound: function () {
|
|
|
|
return (!!this._signal && !!this._listener);
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#isOnce
|
2013-10-01 15:39:39 +00:00
|
|
|
* @return {boolean} If SignalBinding will only be executed once.
|
2013-10-01 12:54:29 +00:00
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
isOnce: function () {
|
|
|
|
return this._isOnce;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#getListener
|
2014-10-21 22:08:16 +00:00
|
|
|
* @return {function} Handler function bound to the signal.
|
2013-10-01 12:54:29 +00:00
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
getListener: function () {
|
|
|
|
return this._listener;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#getSignal
|
2014-10-21 22:08:16 +00:00
|
|
|
* @return {Phaser.Signal} Signal that listener is currently bound to.
|
2013-10-01 12:54:29 +00:00
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
getSignal: function () {
|
|
|
|
return this._signal;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-01 12:54:29 +00:00
|
|
|
* Delete instance properties
|
2014-07-02 14:25:07 +00:00
|
|
|
* @method Phaser.SignalBinding#_destroy
|
2013-10-01 12:54:29 +00:00
|
|
|
* @private
|
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
_destroy: function () {
|
|
|
|
delete this._signal;
|
|
|
|
delete this._listener;
|
|
|
|
delete this.context;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2013-10-02 10:22:20 +00:00
|
|
|
* @method Phaser.SignalBinding#toString
|
2013-10-01 12:54:29 +00:00
|
|
|
* @return {string} String representation of the object.
|
|
|
|
*/
|
2013-08-28 06:02:55 +00:00
|
|
|
toString: function () {
|
|
|
|
return '[Phaser.SignalBinding isOnce:' + this._isOnce +', isBound:'+ this.isBound() +', active:' + this.active + ']';
|
|
|
|
}
|
|
|
|
|
|
|
|
};
|
2013-12-30 16:54:00 +00:00
|
|
|
|
|
|
|
Phaser.SignalBinding.prototype.constructor = Phaser.SignalBinding;
|