* 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.
* If a window (like the PythonShell) owned a context and only stopped it
on destruction, it would be destructed after the global shutdown
destroyed the interpreter.
* This allows us to return complex types like byte arrays or pairs of
status & render handle.
* Also in future more introspection of the capture file will be possible
and this provides an easy extension to that without adding new entry
points.
* 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).
* Note, this API is still in-flux and beta, so there may still be some
more changes before it's 'stable', and even then it will still be
subject to some amount of change.
* This API is then exposed to python via SWIG bindings and hides
internals that don't need to be visible, and means the actual API is
easier to work with.
* We also use this API to reduce inter-dependencies between different
windows that need to interact with each other at a high level.
* The naming is python/standard RenderDoc TitleCase method names, not
Qt style camelCase methods.
# Conflicts:
# qrenderdoc/Windows/PipelineState/D3D11PipelineStateViewer.cpp
# qrenderdoc/Windows/TextureViewer.cpp
* 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).
baldurk