* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* One automodule in a file for our modules is way too much, so we split it into
files. Unfortunately this means that only one file can have those classes and
functions be linkable from elsewhere.
* Instead we bite the bullet and manually curate the items into pages, and at
the same time subdivide the 'enums and data' page more which is a general
readability and usability win as well.
* We also add some previously not-included functions, and add a doc-build time
check to ensure that functions and classes aren't omitted from the
documentation in future
* Non-integer DPI handling is fundamentally a broken concept, because UIs are
essentially pixel art with some vector drawing. Rounding down half fractions
seems to be a better tradeoff than rounding up or trying to render them as-is.
* It's required for replay applications to call InitialiseReplay() before doing
any work, and to call ShutdownReplay() once they're finished.
* This lets us do more heavyweight shutdown work before global destructors are
being invoked and the RenderDoc instance is being destroyed.
* Anything that needs to be shut down during capture still has to happen in
RenderDoc::~RenderDoc since we obviously can't get the application to call a
shutdown function in that situation.
* This is only lightly tested and may break heavily. It is disabled by default
and must be explicitly enabled.
* In particular this is only known to work for Wayland use at capture time.
Wayland on replay is still unsupported. Known issues include: EGL pbuffer
surfaces are not implemented on Wayland, Wayland cannot get window dimensions,
and there are hangs/failures with GL and vulkan presentation with Wayland.
* This allows RemoteHost handles to still be valid and usable (if returning
empty data) when they are deleted/removed if the device is disconnected, as
well as providing better multi-thread access (they lock internally)
* We also only use GIT_COMMIT_HASH where necessary to avoid rebuilding many
files for no reason, including splitting version.cpp out into a separate
project as we do with VS since otherwise changing its preprocessor defines
rebuilds the whole renderdoc project.
* At the same time, move the git hash to be internal only so we don't have to
try to link version.cpp into other projects like renderdoccmd or qrenderdoc.
* This has some possible problems - e.g. if one copy of qrenderdoc is closed and
kills the server used by another copy. However it seems impossible to reliably
manage adb and we need to ensure we don't leave the process lingering around.
* At the moment 95% of users don't use android, so it's most important that they
have a smooth experience.
* This was the cause of problems around updating versions because adb.exe would
hang around and then be 'in use' and not able to be overwritten.
* 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.
* This is a *very* light-touch analytics system that will track the
simplest and most anonymous statistics that can be useful in
determining which features are most used or perhaps underused, and
where it's best to direct development attention.
* It is entirely implemented in the UI layer, no analytics-gathering
code exists in the library that's injected into programs, and of
course no capture data (screenshots, resource contents, shaders, etc
etc) is transmitted.
* Once it's turned on, it will apply to both development and release
builds. It tracks stats over a month, and then at the beginning of a
new month it sends the previous data.
* When the user first starts up a build with analytics if there's no
previous analytics database then they are informed of the new code and
asked to approve it. They have the option of selecting to manually
verify any sent reports, or just opt-ing out entirely.
* This is a leftover from before the interface was hoisted out, and most
windows were still calling directly to CaptureContext instead of via
the public ICaptureContext interface
* 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>
* 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.
* We can point the platform plugins path at the application dir for
qwindows.dll for example, but there's no equivalent for image format
plugins which we need for qsvg.dll. So instead we shove them all under
an explicit qtplugins path.
* Also now that we have this, copy qsvg.dll into the distribution.
* It's not entirely clear if this is the intended fix, but otherwise
since we're not running QApplication::exec() the main event loop has
the same 'loop level' of 0 as the event level when it's fired. The
proper functioning seems to be that the posted deleteLater event
should have an event level of 1 which then means it will be processed
when coming back to the exec() loop level of 0, but since we don't get
that, just run it manually after all other events.
baldurk