* Ideally we'd document every member unconditionally for best autocompletion,
but that's a lot of modification so for now we stick to just making sure that
any members that are struct types (or lists/tuples) have the :type:
declaration so that we can autocomplete inside them.
* Also added a script that can run as part of CI to verify that the docstring
matches, by generating a regex from the docstring documented parameter types
and return type and making sure we find a match within the C headers. This
ensures all parameters are documented with the right types, no extra
parameters are documented, and the return type is correct.
* The script also checks proper scoping so that if qrenderdoc docstrings
mention a renderdoc type, they need to scope it properly.
* 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
* This allows persistent config storage and registering tweak variables that
works independent of the UI's configuration.
* Config vars can be debug only, which means they will be compiled out in stable
version releases. This allows for debug-logging tweaks that are available in
all builds (including nightly builds) for diagnostic purposes, but have zero
overhead in stable releases.
* Variables have a loose hierarchy defined with _ or . to separate nodes.
* This lets the user override the default application font.
* Unfortunately Qt seems to behave inconsistently with font scaling from the
system, so we take the font size initially from QApplication::font() (which
doesn't always pick up the font size) and scale from there. While this might
cause some font scaling to be lost it does mean at least we have a consistent
scale, as otherwise you get some text scaling and others not.
* If the UI was launched with a filename as a parameter to open the capture, it
will be added to the recent capture file list. Only later (relatively
speaking) if we make a capture connection will we realise that it is temporary
and potentially delete the file. If we do so, remove the capture from the
recent file list.
* The defaults can be configured from the settings menu, and there's a new "Open
Capture with Options" menu option to open a capture with different options
temporarily.
* 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)
* The apk targets api level 21 which is 5.0, so it still won't install on
anything older.
* We pop up a big warning to the user the first time they try and select such a
remote host.
* Instead of just configuring SPIR-V disassemblers and picking only the first
one when we need to edit SPIR-V, we allow setting up any shader processor that
goes between two shader encodings.
* When editing, the default will still be to use embedded source, and then after
that the first tool that goes from the native shader format to a text format,
but the drop-down allows you to pick any of them.
* Similarly in the shader viewer you can configure the compilation options and
method, to choose the compiler you want to use. Embedded command line
parameters in the shader are automatically appended.
* We don't consider anything else, this includes permissions or the
library being present. Since we no longer expect to patch in the
library we also don't check its version (however we leave the tag in
case it is useful in the future).
* If the user has root access we will never warn, assuming the injection
will work fine even without the debuggable flag.
* Initially add support for spirv-cross and spirv-dis.
* When possible we'll auto-detect the tools in path or in the build's
plugins folder. Otherwise the user can add it and add their
executable path.
* We still use the first disassembler for editing - in future it would
be good to allow selecting the disassembler at edit time (as well
as allowing multiple compilers).
* The main addition here apart from some extra stubs is a new rdc type
for date time objects.
* Although the module doesn't do anything and is only used for docs
reflection it is desirable to not have to link against Qt as this
can cause problems when linking the module without unresolved symbols.
* 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.
* 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.
* 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.
* In future one of the notes items would be for gathered hardware info.
Not automatically, but with one button press the full configuration
can be embedded.
* Log is an overloaded term since it can also mean the debug log. We now
consistently refer to capture files as capture files or just captures
for short. The log is just for log messages and diagnostics.
* The user-facing UI was mostly already consistent, but many of the
public interfaces exposed to python needed to be renamed, and it made
more sense just to make everything consistent.
* The bug seems to happen if two raw strings concatenated together are
large enough, so instead we pass them as separate parameters to a
different macro then concatenate them inside the macro.
baldurk