* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* When a port is specified (with the usual :12345 suffix on the hostname) we use
that for remote replay connections. We disable target control enumeration
since that requires a port _range_ and captured applications self-assign those
ports. Those can still be accessed via a normal unsuffixed remote specifier -
even if there is no remote server running on the default port.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* The timestamp base is queryable from the capture file and settable too, and
conversions preserve un-rebased timestamps. Only rebasing when loading a
capture for replay.
* This allows persistent config storage and registering tweak variables that
works independent of the UI's configuration.
* Config vars can be debug only, which means they will be compiled out in stable
version releases. This allows for debug-logging tweaks that are available in
all builds (including nightly builds) for diagnostic purposes, but have zero
overhead in stable releases.
* Variables have a loose hierarchy defined with _ or . to separate nodes.
* Mostly moving includes from common headers to cpp where possible, and removing
includes of the whole thing where only enums or rdcstr etc are needed.
* This allows it to tick faster when e.g. loading a capture that takes a while
without any pings. It also allows it to continue going for a short while after
the remote server shuts down to capture any crashdump messages.
* This makes post-mortem debugging easier. It's only active while a remote
server connection is running, so e.g. it will miss crashes of the remote
server itself, this could be improved by adding a margin where it will still
check for messages after the connection is dropped - perhaps on a separate
thread.
* Any time the replay types serialisation change, the remote server becomes
incompatible. We're not going to add backwards compatibility to that system,
so we need to break it every time.
* Really the version should be bumped any time renderdoc_serialise.inl changes,
but we don't have an auto-incrementing revision to use.
* If android studio or other android tools are open when a package is
launched for debugging, they greedily jump on it and connect which
prevents us from connecting.
* We can't reliably know when we can safely remove the layer property
at capture time because it's impossible to know if an android app will
use vulkan or not. So instead we fall back to unsetting it whenever we
need to - before opening a capture or when shutting down the remote
server (in case after capturing, no frame capture was actually opened)
* This means that if the UI crashes without unsetting it, we will poison
the state, but this seems unavoidable.
baldurk