NEW: Added achievable frequency and latency (processing delay) to Input Debugger (ISX-2254)

[ekcoh]

Description

Adds achievable sample/event frequency (as well as sensor frequency and global polling frequency) to Input Debugger device window. These are just basic calculations over periods of one second at the moment similar to FPS counter.
Adds input processing delay (average, min, max) to Input Debugger device window.

The diagnostic values are similar to FPS updated once a second to show primarily the average. This is intended to help with diagnosing the behaviour of the system and devices and help spot problems.

Added 11 new test cases to cover the calculators as part of editor test assembly which required modification to accept unsafe code in the test assembly which I believe should be ok to change.

Target frequency shown is based on IOCTL sample frequency query response which I believe is only supported by sensors currently. Polling frequency is as we know global at the moment, but showing it since it relates to devices with polling backends which we currently cannot determine from the system. If both of these could be capability queried in the future we can make a better message here.

Testing status & QA

Tested manually with mouse, keyboard and gamepad on macOS during development.
Added unit tests to verify that calculations are working as expected.

Overall Product Risks

Very small. Has no impact on production or player code.

• Complexity: 0
• Halo Effect: 0

Comments to reviewers

If possible to cover sensors in review/QA it would be great.

Note that both label fields have tooltip that also needs review.

Checklist

Before review:

• Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
  • Jira port for the next release set as "Resolved".
• Tests added/changed, if applicable.
  • Functional tests: 11 new test cases added to InputLatencyCalculatorTests and SampleFrequencyCalculatorTests.
  • Performance tests.
  • Integration tests.
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

After merge:

• Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

[ritamerkl]

It's a great to have, thanks for adding this!
I only did a quick run through but it looks good from my POV. I need to take another closer look and try it myself.

[ekcoh]

Target frequency is currently only a "convient storage" here. Hower I would suggest keeping it inside this type since an evolved implementation will likely use it to compute error compared to target and create a CDF or PDF of it to illustrate the applications or architectures ability to promptly react to stimuli.

[surfnerd]

I think this is great step toward transparency of processing of input events. I think it should be made clear that this doesn't measure the latency between the creation of an input event to when it shows up on the screen, but from the creation of the event to when it's processed by the input system.

[ekcoh]

I think this is great step toward transparency of processing of input events. I think it should be made clear that this doesn't measure the latency between the creation of an input event to when it shows up on the screen, but from the creation of the event to when it's processed by the input system.

Agreed, that's a much simpler/better way to say what I am trying to say in that tool tip. Also why I renamed the label to "Processing Delay". Will try to improve the tooltip based your description here. Thanks! :)