The only thing I can see which could cause this is reading from the `drawClock.ElapsedFrameTime` after the `isSpike` read causing a div-by-zero. Reading the values once at the start should avoid this.
I'm not sure what I was thinking with the weighting stuff. It wasn't
correct. Can most easily be noticed if suspending the app on iOS for a
considerable period, or pausing debugger.
While on the surface this looks harmless (ignoring allocations),
`Scheduler` doesn't clear cancelled tasks until they reach their
execution time. This can cause an increase in time spent processing the
scheduler itself.
I don't think a per-frame updating component should use scheduled tasks
in this way in the first place, so I've just rewritten the logic to
avoid that overhead altogether.
It wasn't made to be updated every frame, and it shows. Inaccurate for
reasons I'm not really interested in investigating, because I don't want
to incur the `Transorm` overhead in the first place for an fps counter.
Was only used originally out of convenience.
Had a feeling this would be the case.
Basically, we're calculating on the update thread and checking the last
value of draw thread's `ElapsedFrameTime`. In the case that value is
spiky, a completely incorrect fps can be displayed.
I've left the spike display do use `ElapsedFrameTime`, as
`FramesPerSecond` is too averaged to see spikes.
