NEW: add touch test measuring input system profiler markers

[stefanunity]

Description

• see title.
• similar test to MeasureInputSystemFrameTimeWithProfilerMarkers_FPS() just with touch instead of mouse&keyboard input

Testing status & QA

• test runs
• data submitted to hoarder

Overall Product Risks

• none, internal tests

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 Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • 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.

[jfreire-unity]

Looks good to me.
Maybe add some top level comments to explain what it does for this particular test?

One suggestion will to be clear on of what we want to measure this against to. I know we already do test doing nothing, doing keyboard and mouse input in Performance_MeasureInputSystemFrameTimeWithProfilerMarkers_FPS but it contains actions so it's not a 1 to 1 comparison. Should this test also contain some actions setup?

[ekcoh]

I guess changes look ok here but I wonder what scenario we are trying to replicate here? It seems that there is not many touch points per frame here, essentially looks like one touch update per frame. That is fine given a e.g. 30 or 60 Hz touch sensor , but I believe most these days generate higher frequency of touch. It might be meaningful to measure a decently modern touch screen and take the actual achievable frequency. I wouldn't trust just reading specs since the HW frequency might be higher than what you get out of the driver.

[ekcoh]

It be good to outline the intended scenario as clearly as possible in the test description or inline (Seems like @jfreire-unity suggested something similar.

[ekcoh]

Approving this as is but I think we should consider relevance of scenario.

[ekcoh]

Is this still work in progress or why Draft status?