CHANGE: ISX-2322 Rely on module (and platform) to manage polling frequency. #2200
Conversation
ekcoh
changed the title
…ogies/InputSystem into isx-2322-polling-frequency
Codecov ReportAll modified and coverable lines are covered by tests ✅ @@ Coverage Diff @@
## develop #2200 +/- ##
========================================
Coverage 68.11% 68.11%
========================================
Files 367 367
Lines 53633 53638 +5
========================================
+ Hits 36530 36535 +5
Misses 17103 17103
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes 🚀 New features to boost your workflow:
|
ekcoh
changed the title
|
Looks like asmdef condition is true for trunk which it shouldn't be, will make sure related Unity PR is on-par with trunk investigate. |
… contain required changes. Note that to test one has to weak this asmdef.
|
As suspected trunk had advanced hence asmdef is now a3 to exclude trunk. Note that during testing you have to modify the asmdef to be a2 when tested with the corresponding Unity branch. |
| public void Devices_PollingFrequencyIsAtLeast60HzByDefault() | ||
| { | ||
| Assert.That(InputSystem.pollingFrequency, Is.GreaterThanOrEqualTo(60)); | ||
| } |
There was a problem hiding this comment.
Can we also run this test when we check XInput on Windows? I'm not sure if its ideal to do this on the package but I'd like to test that this pollingFrequency is at least affected by platforms that do expose it.
There was a problem hiding this comment.
This is just a setting. The KPI branch on module "sampling performance" is testing exactly that.
There was a problem hiding this comment.
Then I also added the achievable frequency to input debugger long ago. If you set this to 250 you might get what the device and system conditions support. e.g. 125
|
Are these CI failures expected? |
|
Doing the actual testing I genuinely didn't see any differences at all, the Input Debugger reports my Xbox Controller Polling Frequency as 60 Hz both when using trunk or the required editor PR. Nothing seemed broken or different at all in the actual gamepad scenes as well. So I felt like I must be checking things wrong or maybe that's fine? 🤷 |
Compile errors are expected if the asmdef isn't matching the Unity version it got merged into. I will update this PR accordingly to match trunk. |
|
Updated asmdef files to map to Unity version containing relevant functionality to support this. Seems however difficult to verify this on macOS at the moment since polling frequency seems to be ignored so need to revisit when I have access to a Windows machine where its more straightforward to verify this. |
ekcoh
changed the title
|
I updated the description after my latest testing. I used the following script to change the polling frequency as part of entering play mode to verify: using UnityEngine;
using UnityEngine.InputSystem;
public class PollingFrequency : MonoBehaviour
{
// Start is called once before the first execution of Update after the MonoBehaviour is created
void Start()
{
InputSystem.pollingFrequency = 50.0f; // Change target polling frequency from default
}
}``` |
|
Fixed an issue in b4971d3 which caused a test to fail since the test runtime polling frequency wasn't initialized inline with valid value range. It is now initialized to 60 Hz which is the default. |
|
@Pauliusd01 sorry, I re-asked your review withouth knowing you add approved it 2h ago. feel freee to approve again! |
|
Thanks for review and testing, will merge this one as soon as CI has rerun. |
Description
Removes polling frequency as a property being managed by
InputManagerand instead delegates life-time and initial setting to be configured by platform and input-module. This requires a specific Unity branch, see internal issue ISX-2322.Also removed double-booking of pollingFrequency field from serialised state since I cannot see any reason to have it part of serialised state. Since property is now in native it won't be subject to domain reloads.
.asmdef files guarding for the underlying functionality has been set to 6000.3.0a6 which contains the required functionality.
Testing status & QA
Tested on macOS by setting native polling frequency to 123 Hz with a custom local build during development.Recommended to test on Windows with Xbox gamepad on the associated Unity branch since Windows has a higher default than 60 Hz on that branch which affects the Windows Gaming Input backend. E.g. testing with a DualSense on Windows wouldn't make much difference since DualSense is using unconstrained polling at the platform level and do not depend on polling frequency setting.
Tested on macOS by seeing that default polling frequency is set to 60 Hz. However, this doesn't matter given the current backend implementations which do not rely on this but use underlying frameworks that are uncorrelated to it.
Tested on Windows with an Xbox gamepad which is currently one of the few ways to actually hit the associated functionality. Out of the box the target frequency is now 1000 Hz on Windows. But as can be seen in Input Debugger the polling frequency saturates as 125 Hz which is the maximum for an Xbox gamepad. Changing target to e.g. 200 Hz still produces 125 Hz. This is expected. Setting it lower, e.g. 60 Hz however rate-limits the polling frequency in the backend to this frequency. See screenshots below. Not that DualSense on Windows runs at "infinite frequency" so it would just yield saturated max frequency regardless this setting and this makes that device unfit for testing.
Overall Product Risks
Small.
Comments to reviewers
Note that this branch should be merged after the corresponding Unity feature branch has landed since version is otherwise unknown: update changeling, comments and asmdef condition
Checklist
Before review:
Changed,Fixed,Addedsections.Devices_PollingFrequencyIsAtLeast60HzByDefaultconditionally replacesDevices_PollingFrequencyIs60HzByDefaultconditionally based on Unity version being used.During merge:
NEW: ___.FIX: ___.DOCS: ___.CHANGE: ___.RELEASE: 1.1.0-preview.3.After merge: