* 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.
Since the pitch is calculated by GetResourcePitchForSubresource, there is no need to calculate it manually, or even erroneously as were the case by using the resource pitch determined by the D3D11 API.
During size estimation phase of serialisation, the row + depth pitch were not conservative enough estimates on some drivers. To remedy this, it's determined exactly at estimation time by attempting to map the resources.
* Tag the RenderDoc layer with a version string that
matches the host, including git hash.
* In developer builds, check the version when scanning the
application for RenderDoc support.
* Pass the warning back to the UI to offer ways to fix.
* Update APK patching to remove existing layer.
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).
baldurk