Description

XRA-675

Fix PoseControl.isTracked always returning false via non-optimized read paths

PoseState.isTracked was declared with sizeInBits = 8 to enable the kFormatPose optimization. However, this caused InputStateBlock.ReadFloat() to treat the bool byte value as an 8-bit normalized quantity (1/255 ≈ 0.004) instead of a discrete 0.0 or 1.0. Since 0.004 falls below the 0.5 button press threshold, isTracked always returned false when read through non-optimized code paths, including the Input Debugger.

Summary of Changes

PoseControl.cs — two changes:

1. PoseState.isTracked: Changed sizeInBits = 8 to sizeInBits = 1. This makes InputStateBlock.ReadFloat() use the ReadSingleBit path, which correctly returns 0.0f or 1.0f. The struct layout is unaffected - StructLayout(LayoutKind.Explicit) with FieldOffset attributes controls the memory layout independently of sizeInBits.
2. PoseControl.CalculateOptimizedControlDataType(): Updated the isTracked validation from isTracked.optimizedControlDataType == InputStateBlock.kFormatByte to checking isTracked.m_StateBlock.format == InputStateBlock.kFormatBit && isTracked.m_StateBlock.sizeInBits == 1. This preserves the kFormatPose fast path (direct *(PoseState*)ptr struct cast), which remains valid because the C# bool at byte 0 is always stored as a full byte (0 or 1) regardless of the declared bit width.

Testing status & QA

Added the test Controls_PoseControl_IsTracked_ReadsCorrectly - parameterized with [TestCase(true)] and [TestCase(false)] to run with optimized controls both enabled and disabled. For each case it:

• Queues a state event with isTracked = 1 and verifies:
  • poseControl.isTracked.isPressed returns true
  • poseControl.isTracked.ReadValue() returns 1.0f
  • poseControl.ReadValue().isTracked returns true
• Queues a state event with isTracked = 0 and verifies all three return false/0.0f

Overall Product Risks

• Complexity: 0
• Halo Effect: 0

Comments to reviewers

With this fix, isTracked loses its AxisControl-level optimization — it previously got kFormatByte (via sizeInBits = 8), and now falls through to stateBlock.ReadFloat() since AxisControl has no fast path for 1-bit controls. The performance difference should be negligible (both end up reading a single bit), and the kFormatPose bulk optimization is preserved, but it's still a gap.

I looked into adding a kFormatBit optimization to AxisControl so that 1-bit ButtonControls get a direct ReadSingleBit fast path. This would restore the optimization for isTracked, put the PoseControl check back on the standard optimizedControlDataType pipeline, and benefit other 1-bit button in the system (mouse, keyboard, gamepad, etc.). We wanted to bring this up and see if this is worth following up with. The main concern is the wider blast radius — it touches AxisControl, which affects every device type, so it would need a proper audit and test pass.

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.