Relying on TypeId being some hash internally isn't future-proof because there is no guarantee about internal layout or structure of TypeId. I benchmarked TypeId noop hasher vs fxhash and found that there is very little difference.
Also fxhash is likely to be better supported because it is widely used in rustc itself.
[Benchmarks of hashers](https://github.com/bevyengine/bevy/issues/1097)
[Engine wide benchmarks](https://github.com/bevyengine/bevy/pull/1119#issuecomment-751361215)
Previously, if the actual value of LeftStickX was e.g. 0.034 and fluctuated a little
bit (less than the threshold) it would repeatedly send out events,
because it compared the value to the *filtered* old one - 0.0 - which is
more then `0.01` (the threshold) away.
The is fixed by first doing the deadzone and then comparing to the old
value.
Another possible solution would be to store both the actual old value
and the filtered one, but that would add complexity.
improve quality of text2d rendering
* remove coordinate tweaking in sprite-sheet shader
* fixes glyph shimmering of animated text
* reposition glyph before passing it to ab_glyph to normalize its rendering
The result of layout of sequence of glyphs causes individuals to have fractional positions, but since glyph renderings are reused for future instances of that glyph, this produces errors. This change accepts the errors but repositions the glyph to "0, 0" in an effort to get the cleanest possible rendering.
make more information available from loaded GLTF model
* make gltf nodes available as assets
* add list of primitive per mesh, and their associated material
* complete gltf structure
* get names of gltf assets
* only load materials once
* add labels with node names
* Test entity labels, fixed corner cases, changed interface
* add tests for entity_labels_system
* fixed filling label_entities map
* fixed corner cases when removing entities, Labels component
* changed EntityLabels::get to return slice or empty slice instead of
None or Some empty or non-empty slice
Changing the interface of EntityLabels::get is beneficial, since else
you would get different results in case there was an entity before that
with this missing label or not. You would either get None or Some(&[])
and need to handle both, which is actually not necessary.
* register type Labels in CorePlugin
* move print diagnostics to log
* entity count diagnostic
* asset count diagnostic
* remove useless `pub`s
* use `BTreeMap` instead of `HashMap`
* get entity count from world
* keep ordered list of diagnostics
