There are a bunch of signals added for Sprites; more when input is
enabled. However, very few of these signals are ever actually used. While
the previous performance update related to Signals addressed the size of
each Signal object, this update is to reduce the number of Signal objects
as used by the Events type.
As a comparison the "Particle: Random Sprite" demo creates 3200+ Signals;
with this change there less than 70 signals created when running the same
demo. (Each Event creates at 8 signals by default, and there is an Event
for each of the 400 particles.) While this is an idealized scenario, a
huge amount (of albeit small) object reduction should be expected.
It does this by creating a signal proxy property getter and a signal
dispatch proxy. When the event property (eg. `onEvent`) is accessed a new
Signal object is created (and cached in `_onEvent`) as required. This
ensures that no user code has to perform an existance-check on the event
property first: it just continues to use the signal property as normal.
When the Phaser game code needs to dispatch the event it uses
`event.onEvent$dispath(..)` instead of `event.onEvent.dispatch(..)`. This
special auto-generated method automatically takes care of checking for if
the Signal has been created and only dispatches the event if this is the
case. (If the game code used the `onEvent` property itself the event
deferal approach would be defeated.)
This approach is designed to require minimal changes, not negatively
affect performance, and reduce the number of Signal objects and
corresponding Signal/Event resource usage.
The only known user-code change is that code can add to signal (eg.
onInput) events even when input is not enabled - this will allow some
previously invalid code run without throwing an exception.
- Updated `readOnly` doclet to `readonly`
- `array` refined to `type[]`, where such information was immediately
determinable.
- Updated {Any}/{*} to {any}; {...*} is standard exception
- Udated {Object} to {object}
The substraction of `physicsElapsedMS` needs to be done for all individual
updates. (When current FPS ~ target FPS this is a 1-1 mapping, but catchup
updates can throw off the calculations.)
Also renamed `Game#updateNumber` (a poor initial name on my part) to
`currentUpdateID`. This matches the naming of
`Stage#currentRenderOrderID`.
Some minor cleanup of font component handling and comments.
Also adds a warning if an "unparsable font" string is encountered. Might
save someone some trouble.
Fulfills: https://github.com/photonstorm/phaser/issues/1370
This allows `fontSize` and `fontWeight` to be specified as part of the
style as supplied to the Text constructor (and `setStyle` method). In
addition the `fontStyle` and `fontVariant` properties can also be set -
although these are not exposed later.
This also fixes edge cases that could be caused if `Text#fontSize` was
used without `Text#fontWeight`, where the applied style defaults would be
overwritten/reset.
- Added @deprecated/@readonly to various some properties but public properties maintain the same semantics
- Also removed some "cleverness"
- Still same good fixes ..
- Fix incorrect passing of "was clicked" to processInteractiveObjects
- Button would not return to Over/Out state because of strict too check to catch `undefined`
- Removed [undocumented] property usage from processInteractiveObjects and slight reformatting
- Update Button state frames/sounds to remove duplication
- Updated documentation in Button for consistency
In function override Phaser.Text.prototype.updateText(), don't include this.context.lineWidth in width calculation as it's already incorporated by this.style.strokeThickness.
BitmapData.getBounds will return a `Rectangle` object that encompasses the full extent of the non-transparent pixels in the BitmapData. This can be useful if you wish to trim away transparent pixels from the sides of a BitmapData down to size before saving.
