* We need to update the scrollbar bounds first based on the current zoom level,
then change the scroll position. Otherwise the scroll will be visually correct
but the scrollbars won't match.
* We still need to handle multiple elements in the root of a struct specially by
commenting out the fixed members, but the final element needs to go through
the normal DeclareStruct() path to handle things like per-column padding in
matrices etc.
* The crash handler gets destroyed and recreated when we need to change creation
parameters, and this races against anything else trying to use it to register
or unregister memory regions.
* In partcular when initialising the replay we recreated the crash handler right
after kicking off the GPU enumeration.
* We add a read/write lock so there's no significant added contention on most
paths (even though it's not really high traffic in any case) to prevent this
kind of problem in future.
* Add CATCH_CONFIG_FORCE_FALLBACK_STRINGIFIER to force use of ToStr in
all cases. We can handle ints, etc, we don't need ostringstream, and
this allows us to handle enums that would otherwise just be printed as
their integer value.
* Add CATCH_CONFIG_INLINE_DEBUG_BREAK which restores the Catch 1.0
behaviour of debugbreaks happening in macros and so in-line at the
actual site failure. So the debugger stops on the CHECK() or REQUIRE()
call instead of inside AssertionHandler::complete()
Cherry pick from https://github.com/baldurk/renderdoc/commit/4232736fc21fc6a13a4de6997a5ae106598b225f
xcode project generation is driven by the sources list
before this commit "pipestate.inl" was not present in the xcode project
after this commit it is present
* This can be out of bounds when purely considering the instruction index if
there's an instruction near the end, beyond the point where there are (many)
further values.
* If we serialise from the map, and then separately memcpy from it to populate
the reference data then we risk another thread's writes happening in between
and not being detected on subsequence checks. Instead we need to copy from the
serialised data, that way regardless of what we snapshot there we always
compare against it to detect any further writes.
* We used to allow applications to call vkFlushMappedMemoryRanges on coherent
memory to manually annotate regions of memory that are changed in persistent
maps, thus avoiding the overhead of RenderDoc needing to check for changes on
each submit.
* Unfortunately this means that if the application calls flush wrongly then
changes will no longer appear, even though the application was completely
correct, if misleading, since by the spec behaviour vkFlushMappedMemoryRanges
is a no-op on coherent memory so incorrect calls to it make no difference.
* Since applications making use of this are rare or non-existant we just remove
the optimisation.
baldurk