* In a couple of places I had to resort to if(IsHighContrast) but mostly
this is just using system brushes consistently or not assuming black
text.
* The default DockPanel theme doesn't work well, so make a minimal high-
contrast theme for it and assign it everywhere.
* The pipeline flow was using fixed colours, use system brushes for the
different elements and switch based on high-contrast to ensure active
and inactive stages are visible (using ActiveCaption looks bad on
normal themes because it's a big block of colour).
* For some reason the flat toolstrip renderer doesn't handle white-on-
black themes, but the system one does. It's a little clunkier but it
shows up correctly without writing tons of custom painting code.
* Range histogram uses a properly contrasting colour for the border.
* Treelist views use a better system colour for selected rows when
inactive and hovered rows (when high contrast).
* Mesh view grids have a system background instead of white
* Various things (pipeline state, mesh viewe) set text colour when
colourising backgrounds of things instead of assuming black.
* In-application API is bumped to 1.1.0 as a new function pointer is
added to the end of the structure.
* This comes with some caveats - capturing a frame is fairly heavy
weight, so capturing a frame might throw off timing-related bugs you
are trying to capture in subsequent frames. If you know your bug is
every other frame though, capturing two can be a quick way to ensure
you get it.
* 99% of the time, you'll only have localhost and the application will
be running on the first ident checked which will return a valid socket
almost immediately.
* Instead of continuing to search through each valid port before
returning valid data, we change the enumerate function to just find
the next valid port and return - so we can update the UI as soon as
we have the first result.
* I don't like the fact that it doesn't "just work" but this is mostly
limited by design decisions on the side of the vulkan loader.
* There is no good way with the loader to say 'please also include this
layer in the enumerated lists'. There is an all-or-nothing override of
layer searching, but that would break any layers the application might
actually rely on.
* On balance I've decided to go with this method, as it's a one-off
interruption for the user (unless someone is constantly switching
between installs).
* Apparently Application.Exit() doesn't close immediately and can throw
an exception, leaving the UI open while the updater tries to run and
nothing works. Environment.Exit(0) should do better hopefully.
* 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.
baldurk