* This API is now intended to be forward and backward compatible as much
as possible. Meaning applications should be able to run without
changing on many RenderDoc versions after the one they are built
against without breaking.
* All function pointers are fetched at once in one versioned GetAPI()
function, to save on constant GetProcAddress/dlsym'ing.
* Otherwise, it's largely similar to the previous API.
* This seems way more reliable and smaller than shipping a compiled .dll
* For some reason I didn't find this method before (I only knew that
you could ship the loose files which wasn't a good solution).
* Previously if a temporary log was saved once, it would be moved there,
so the user could in theory delete it and lose the only copy of the
log.
* Now the temporary log is held until it's closed in the UI, to be able
to be saved again. If the user saves the log though, this will stop
any "unsaved log" prompts in the main UI window, so there is nothing
stopping the user from saving the log, deleting that copy, then
closing and they'll lose the log without prompt.
* The option will enable monospaced fonts for all data displays, like
the list of events, API calls, etc as well as pipeline displays, entry
of filename/directory in the capture window and many other places.
Pure UI labelling etc mostly still stays as a serif font.
* A few sizes of controls were tweaked (like headers in the pipeline
windows) so that they didn't just barely overflow with the larger
font.
* While looking at this, it became obvious that buffer viewers and
constant bufferviewers should always display in monospaced regardless,
so that has been changed.
* Errors like syntax and runtime errors in python are thrown as
exceptions. So for when we invoke onto the renderer thread to do some
work, we need to be able to catch those exceptions otherwise the whole
program dies. So over the execute, temporarily switch the thread into
a catching-exception mode, which then gets rethrown on the invoker's
thread.
* Note that BeginInvoke shouldn't be used by python since the callback
might happen after the execution has finished (there's no way to wait
at the moment).
* You can't set SplitterDistance unless both MinSize values will be
respected, which needs a big enough window. Smaller than that, we just
have to skip setting the size.
* For each texture you view, it will reset back to mip 0 and slice 0
as it previously did, and it will also reset the channels back to
RGB only, which is new behaviour.
* Then each texture remembers those settings, so if you choose to view
slice 6 & alpha only of a texture any time you switch back to it
you'll see slice 6 & alpha only.
* It can be disabled in the options, but this is the new default
behaviour. Possibly in future the zoom level and visible range might
be rolled into this, but for now I think they might work better as
global state.
* Has a couple of limitations - won't check deferred context or
NO_OVERWRITE Map()s except in a captured frame. This could in theory be
implemented but it'd be complex and I don't want to complicate/break
the normal path.
* When an overrun is detected, a messagebox pops up to block the thread,
and if you hit yes, it will debugbreak.
* This allows you to hook into processes that are difficult to launch
directly with the existing functionality in RenderDoc.
* This is rather risky, as it modifies the AppInit_DLLs registry key to
inject a small shim dll that checks for the desired process and injects
the full renderdoc.dll. If that registry key got left, or if there was
some incompatibility with the shim dll, you could have problems. It
should only ever be used as a last resort if there's no other way to
capture.
* Whenever a child process is hooked, that's passed back up to the UI and
a list is shown with all the child processes of the one you are connected
to in the dialog.
* At any point you can double click to create a new dialog latched to that
process.
* If the process you're attached to closes and has one child, similar to if
you only have one capture made the dialog will close itself and open a
new connection to the child process. This is the case for e.g launcher ->
editor
* This behaviour is overridden if you made a capture, as it assumes you
then don't care about the child processes and instead want to open the
capture. You can always do file -> attach later.
* If it has multiple children when the process closes, the dialog stays
open to allow you to peruse the list and maybe open up a connection to
one of the children.
baldurk