This is part of the work specified by github Issue 586, allowing the
ability to save out the overlay in the TextureViewer. If no overlays
are on then there is no option to save the overlay. Currently there is
no option to remap the overlay to a grayscale or absolute value range
before saving. This can be a future task.
NOTE: the overlay texture resource that's saved out is not the blended
texture that the user will see in the TextureViewer, it is just the
overlay itself. The ability to save out the blended texture would be a
future task.
* We search first in specified folders by the user (they can browse to
the android SDK and java JDK).
* If the tools we want aren't found there, we look relative to the UI
as we now distribute the required tools with windows builds.
* If we still don't find them, we prefer to look in PATH since the user
has 'opted in' to any tools found in there. If the tool isn't in PATH
either then we look relative to known environment variables.
* This will enable the last few python list emulation functions, like
index (which needs operator== to find objects) and sort (which
obviously needs operator< to sort).
* This is to support python bindings - the pyside implementation of
QVector, QString, etc is not available to SWIG, so SWIG treates these
all as opaque types.
* Rather than trying to set up bindings that work for rdcarray and
QList/QVector, or implementing separate bindings, we instead just say
that the public interface must use the rdc types. In most cases they
seamlessly convert to/from Qt types anyway.
* In a couple of places we use an array of pairs instead of a map. In
future we probably want an rdcdict or rdcmap with proper dict bindings
in python.
* Previously we'd cache a copy of each command buffer at load time, and
submit it any time we're not partially re-recording. This has a couple
of drawbacks though:
- Technically we do some things that invalidate those command buffers,
like updating descriptor sets (with initial state application) and
so for 100% correctness we'd need to re-record.
- It also means that any edits we apply, like modified shaders, don't
properly apply to the whole frame, they only apply to whichever
command buffer is currently being partially recorded.
* We refactor out the 're-record all commands' behaviour previously
reserved just for applying GPU counters, and use that for re-recording
any command buffers that are wholly or partially submitted. Note that
it's still true that only one primary and one secondary at most are
actually *partially* re-recorded. The others are re-recorded in their
entirety.
* We almost always mean DXGI_FORMAT_R10G10B10A2_UNORM instead and the
xr bias format is rarely used (so unlikely to be the right
interpretation) and might not work at all.
baldurk