* The GUIInvoke object takes a QObject, and uses QPointer to check that
it hasn't been deleted when the callback fires. This prevents delayed
callbacks from executing after the object has been deleted and
crashing.
* In most cases the pointer is just 'this'.
* 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.
* Instead of replaying predication, we now always skip it during replay,
so all objects will render. This is much more consistent and
understandable behaviour instead of things mysteriously disappearing
with no obvious reason why.
* We track the predication that would have happened and replay Begin/End
pairs so that we can know if the predication *would* have failed.
* This is displayed in the UI (currently in the raster state, for lack
of a better location) with the pass/fail that would have happened.
* This information can feed into other places for analysis like the
pixel history.
* 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.
* Reported by Coverity Scan. In all cases, should not be a problem, but
with an upcast happening anyway we might as well ensure calculation
happens at a higher precision.
* Reported by Coverity Scan - most of these are not an issue and a
couple of them are coverity getting really confused (like seeing a
pointer being assigned to NULL and a count to 0, then a few lines
later declaring that a loop 0..count will dereference the pointer).
* However it's harmless in all cases to add a bit of robustness to keep
the analysis happy.
* 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
baldurk