* This includes:
- Incorrect comparisons
- Missing type annotations where it can't be inferred
- Variable shadowing and bad use
- Unused imports
- asserts for non-None on types
* Passes clean on strict pyright checking except for
`reportMissingParameterType`, `reportUnusedVariable`, and
`reportOptionalMemberAccess` which are all too spammy and low value to be
worth addressing.
* These come from long ago when using PyCharm with not as good type checking and
with renderdoc module stubs that were incomplete so needed help identifying
types.
* assert is handled specially by the type checker so we don't want to have
duplicate self.check / assert
* The original reason for TestCase.check was to print the assertion message but
this can be handled by checking for the AssertionError exception
* This helps with type checkers to know that things can be None or not (both to
silence previous warnings about "unnecessary" checks that are actually
necessary, and to ensure those checks aren't omitted by accident)
Transfer writes are not implicitly ordered, so without a barrier the fill could
complete after the copy. This was causing intermittent failures in the
VK_Indirect test when running with KosmicKrisp.
Synchronization validation reports this error:
```
vkCmdCopyBuffer(): WRITE_AFTER_WRITE hazard detected. vkCmdCopyBuffer writes to
VkBuffer [m_IndirectBufferActionCB], which was previously written by
vkCmdFillBuffer[Drawcall callback replay (drawCount=1)].
```
Inside the large EI draw with a count of 256: only check a few EIDs at the start and end of that EI.
Reduces the test time and the EIDs being skipped are not exercising different code paths during replay.
The commands to initialize srcBuf must complete before it is copied. Sync
validation reports this as a READ_AFTER_WRITE hazard. This also fixes a
VK_Image_Layouts test failure when running with KosmicKrisp.
* During capture shutdown on Python < 3.13 the replay thread will try to remove
itself as a debuggable thread which requires being able to run python (holding
the GIL). If the UI thread is the one triggering the capture shutdown and is
running a call from a python script it may hold the GIL while waiting for the
replay thread to close, deadlocking.
* To alleviate this, while the UI thread is about to block on the replay thread
we try to release the python state if we are holding it so that the replay
thread can run python code if needed.
* We already do this in a manual wrapper around BlockInvoke.
* Due to the way Qt works, the owning object acts as if it lives on the thread
which in this case is running an event loop that tries to delete itself.
baldurk