test: Run Cinema 4D 2026 integ tests on GPU.

[karthikbekalp]

What was the problem/requirement? (What/Why)

The Redshift tests were flaky. Maxon developers informed us that Redshift can have unpredictable behavior on only CPU environments.

Their guidance was to run the tests on GPU.

What was the solution? (How)

So, modified the test to run Redshift tests on GPU for Windows.

The reason we only run Redshift tests on Cinema 4D 2026 and not 2024-2025 is:

• 2026 is the most updated version which most of our customers use and hence some coverage with Redshift is useful even though in terms of GUI there's no difference.
• We have other adaptor tests that we run that specifically check complex Redshift scenes internally.
• Running GPU runners is not cheap compared to standard runners which is free.

What is the impact of this change?

No customer impact, but we now run tests for Redshift on GPU.
In the future, we could probably make separate tests that run only Redshift related tests on GPU.

How was this change tested?

Ran the test on CI here: https://github.com/aws-deadline/deadline-cloud-for-cinema-4d/actions/runs/33912280729/job/101170305511

Was this change documented?

No document change necessary.

Is this a breaking change?

No

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

The keyboard stepping loop has no tolerance for a dropped synthetic input event, which is the same class of flake this change is working around:

• combo.focus() / wait_focused() happen once before the loop, but _set_spin_button_value in this same module re-focuses before every press (lines 90-91). If that re-focus is there because macOS can steal/lose focus between presses, this loop needs it too — otherwise presses 2..n can land nowhere.
• If a press is dropped, the per-step combo.wait_until(...) raises xa11y.TimeoutError and the whole helper fails. The pointer-click path it replaces at least had a recovery step (_wait_for_take_selection retries with Enter and a longer 10s window). Since arrow stepping is verify-then-retry friendly (read the current selection, press again if it did not advance), a small bounded retry per step would make this strictly more reliable than the path it replaces rather than trading one flake for another.

Suggest moving focus()/wait_focused() inside the loop and wrapping each step in a bounded retry, mirroring _set_spin_button_value.

[github-actions]

The new macOS recovery path can raise before the Enter fallback is ever reached, which makes this helper less robust than the version it replaces.

Previously, any failure to observe the selection fell straight through to input_sim().press("Enter") plus a 10s confirm. Now, when option.wait_visible(timeout=0.5) fails, we call _open_take_combo(combo) and then _take_option(combo, selection) — and _take_option re-raises xa11y.TimeoutError (or AssertionError if the PID is missing) out of _wait_for_take_selection. So a transient failure to re-locate the row now aborts the test instead of falling back to the keyboard path that used to handle it.

There is also a specific state where this is likely to trigger: if the popup is still open but the row just is not reported visible (scrolled out of view, or a stale snapshot), _open_take_combo toggles the already-expanded combo closed, and the subsequent _take_option then waits 3s + 10s for a row that no longer exists before raising.

Wrapping the reopen/re-locate in try/except (xa11y.TimeoutError, AssertionError) and letting it fall through to the existing Enter fallback would preserve the old behavior:

    if sys.platform == "darwin":
        try:
            option.wait_visible(timeout=0.5)
        except xa11y.TimeoutError:
            try:
                _open_take_combo(combo)
                option = _take_option(combo, selection)
            except (xa11y.TimeoutError, AssertionError):
                option = None
        if option is not None and _press_take_option(option):
            ...