* This is only relevant for static qrenderdoc builds where the python
used isn't the system python, so it needs to locate its libs.
Otherwise the system libpython3.so and libs will be used.
* If it's called every write then it risks spamming the system with
signals and locking the UI thread with constant writes. Checking and
flushing output every 100ms is sufficient.
* In python globals aren't really global, they're just module-level
variables. So to find our _renderdoc_internal we have to potentailly
walk the stack if we're inside another module until we get to the
globals dict we set up.
* Generally this means removing ref out parameters and instead returning
values. In a couple of cases we will want to avoid copies in future
either by returning const references (e.g. to the pipeline state which
is immutable).
* At the same time, some pointless bool return values that were always
true and didn't indicate errors have been removed. They can be added
again if an error condition comes back.
* Some free functions still have out parameters as C linkage doesn't
allow returning user types by value.
* The C# UI still invokes into C wrappers for all the C++ classes, which
handle taking the return value and doing a copy into an out parameter
still for compatibility.
* This means that if we BlockInvoke a python callback, we don't end up
in a deadlock where we're holding the GIL during script execution but
also waiting on the renderer running (which is trying to acquire the
GIL before calling the callback).
* We need to keep a PythonContext (and its globals Dict) around while
we still have some pending callbacks happening. So now the external
code creates a PythonContext and then releases it when it's done, but
the context will hang around until the global redirector object is
destructed, which is responsible for deleting the context.
* The global redirector is deleted when a refcounting cycle is detected
and the dict is unreachable, which only happens after the context is
released.
* Any time a callback is passed to something and converted to a
std::function we add a reference on the global redirector to keep it
alive. When the callback has finished executing we remove the ref.
* This way, any pending callbacks that have been called but not finished
or converted (queued) and not called yet asynchronously will keep the
context object alive to be able to output, handle exceptions, etc.
* Additionally we need to detect when we're being called asynchronously
and handle exceptions separately instead of trying to propagate up the
call chain, because there might not be any more python code up the
chain (e.g. the render manager calling a python callback).
* Using a separate dict for globals/locals for each interpreter means we
still get separation of variables and no persistence where we don't
want it, but removing sub-interpreters means pyside can work as it
uses the PyGILState_ APIs which do not support sub-interpreters.
* We import everything up front then duplicate the __main__ each time we
create a new context so we keep the __main__ pristine and muck up an
individual copy.
* Because sys is now shared, the output redirectors that overwrite
sys.stdout and sys.stderr have a NULL context, and instead they look
up a specific global which contains the actual context pointer.
* SWIG outputs two files - renderdoc_python.cpp with the main actual
wrapping code, and renderdoc.py a small module that does some
bootstrapping on python side.
* We use a custom version of SWIG that generates strong/typed enums in
python based on enum classes, so in cmake we add this custom swig
fork as an external project and compile it before generating the
wrappers. On windows there's a committed version of the SWIG binary
that gets run directly from the .pro or .vcxproj.
* The renderdoc.py gets embedded as a resource on windows or as a C
generated unsigned char array via include-bin on other platforms, so
that we can insert it into the python context without needing it to
sit around on disk somewhere in sys.path
baldurk