* 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
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* In heavy D3D11 workloads the refcounting overhead especially during fast
binding changes was significant. Refactoring the refcounting to work on a
different model and deferring destruction of objects removes most of the
overhead.
baldurk