* Mostly used for passing a progress float back during a long blocking
call like opening a capture or doing a copy.
* This is much more feasible for python to bind to.
* In several cases we just use a tiny lambda that updates a float anyway
since we can't push the progress directly into a progress dialog, but
need to let it query from a temporary in-between float.
* We enforce a naming scheme more strongly - types, member functions,
and enum values must be UpperCaseCamel, and member variables must be
lowerCaseCamel. No underscores allowed.
* eventId not eventID or EID, and Id preferred to ID in general. Also
for resourceId.
* Removed some lingering hungarian m_Foo naming.
* Some pipeline state structs that are almost identical between the
different APIs are pulled out into common structs. Where something
doesn't make sense (e.g. viewport enable for vulkan) it will just be
set to a sensible default (in that case always true).
* Changed scissors to be x/y & width/height instead of sometimes
left/top/right/bottom
* Abbreviations are discouraged, e.g. operation not op, function not
func.
* The UI dialog is now in Qt. We run qrenderdoc.exe with a very minimal
startup to display the dialog and send the report.
* The flow has been simplified to have less text and an easier time to
just click through and send.
* On the first report, the user is gently nudged to enter their email
address for contact and by default the email is saved for next time.
They're not nagged more than once about this.
* Optionally the user can select to upload the capture. This is always
default off, and there is a confirmation dialog making sure the user
intended to select it.
* After the bug is reported, a unique URL is generated and returned
which the user can then click back on to see if there's any update. By
default the UI will also remember the URL and check it every couple
of days and alert the user in the help menu that there's an update.
* When opening a capture file, a format is now available to allow
easy import from another format without a completely different
interface. Only rdc files can be replayed, but any other file can
load and access structured data through the same interface.
* The replay initialisation and capture writing interfaces also use the
RDCFile instead of passing filenames or Serialisers around directly.
Driver initialisation parameters are now entirely private, and don't
need to be exposed - any agnostic metadata like thumbnail, driver, etc
are all accessed via the RDCFile container itself.
* Callstack resolution is now part of the container file, not the
back-end via way of its Serialiser.
* Importers/Exporters to other non-RDC formats are registered in a
similar way to replay/remote drivers.
* It is also then possible to construct an RDC file from thin air, by
creating an empty RDCFile container and filling it with data, then
requesting it to be written to disk.
* Note that while this is public and uses std::string, because it's a
template with specialisations in a .inl the string never crosses a
module boundary - each including module has its own implementation.
* This will be used as part of the upcoming serialisation refactor.
* Some POD structs are still given ToStr implementations as we haven't
yet switched over the serialisation system to expect all structs to
have serialise functions.
* Since these types are more prevalent than originally designed, it
makes more sense to remove the namespace for ease of typing/naming.
* Also add a specialised type 'bytebuf' for an array of bytes.
* This makes mapping easier to SWIG since there's no special casing for
namespaced arrays. Especially so for nested cases like
rdctype::array<rdctype::str> -> rdcarray<rdcstr>
* For the most part the interface is stl-compatible, but we have a few
little changes of our own for convenience.
* This class is still needed after deleting the C# UI, because we don't
want to pass C++ stl structs over module boundaries and possibly run
into hard to diagnose incompatibilities.
* This allows a buidler to customise from e.g. /usr/lib/librenderdoc.so
to /usr/lib/renderdoc/librenderdoc.so - which is harmless since the
library is 'private' and not intended to be linked against directly.
* Force loading librenderdoccmd.so in the Loader
* Build renderdoc as libVkLayer_GLES_RenderDoc.so, link renderdoccmd
against it, otherwise we will get UnsatisfiedLinkError when running
* Instead of checking on the filename, we look for a specially named
exported symbol somewhere in a module that's already loaded.
* This allows us to mark the python module as a replay program, so if
it's loaded into the python interpreter it will be able to use the
replay API.
* This means we won't get an ugly console window popping up when running
renderdoccmd on windows, but if we run it from a terminal then we'll
get output as normal.
* One downside is that cmd.exe seems to snoop the exe type (GUI or
console) and if it's a GUI application it returns to the prompt
immediately. bash for example though waits for process termination.
* The other is that pipe redirects to file don't work properly.
This removes dependencies on deprecated tools "ant" and "android project"
The new method relies on JAVA_HOME and ANDROID_SDK being set.
It also requires specific versions of the Android build-tools (26.0.1) and
platforms (android-23). See updates to CONTRIBUTING.md and our Travis-CI
config for details.
Travis-CI and documentation also roll forward to latest public NDK r14b.
After selecting an application to launch on Android, inspect it to see if
it contains the RenderDoc layer and required permissions. If it does not,
display a warning similar to desktop. When clicked, if only the layer was
missing, offer to patch the APK, uninstall, and reinstall, with the
warning that it doesn't work for all applications (or at all for GLES).
Also provides pointers to how to package the layer yourself.
The process works by using the host temp directory to pull the APK and
modify it. If the steps fail for any reason, the log is populated and
patching is halted.
This allows the library to be used as a Vulkan layer and shared
object for GLES debugging. It was already being renamed in the
distribution scripts. We've been renaming by hand for local
Vulkan development.
* This way it can be used from Qt or any other UI as well.
* The pipes are created internally and just passed as stdin to the
renderdoccmd processes instead of being named pipes.
baldurk