* The bug seems to happen if two raw strings concatenated together are
large enough, so instead we pass them as separate parameters to a
different macro then concatenate them inside the macro.
* In future we could handle async exceptions by storing the exception
information in a std::function derived object (instead of the separate
ExceptionHandling that lives on the stack) and query it out in a new
WaitForInvoke function maybe. Right now we just print the exception
to the output log and abort the callback.
* 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.
* 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).
* 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