* This happens at the application's risk since there's no way to know what
effect the vendor extension will have or even if it will work together with
renderdoc's hooking.
* In many cases these structs are redundant and currently aren't ever serialised
directly or valid to be included in next chains. However it's better to take
the hit now and implement this universally in case new structs are needed in
future. It's easier to keep up with when new structs are added, and it means
we have the compiler checking we've handled all structs and don't forget one.
* There are some specific exceptions for structs that really need special
handling and are just treated as if they're unsupported, on the assumption
that any special handling will be implemented elsewhere.
* On some implementations, external images have lower memory requirements than
an identical non-external image. To account for the replay being non-external
we create both and pick the worst when reporting memory requirements to the
app, so that it allocates enough for us on replay.
* We need a workaround for cubemaps where our redundant-glTexImage2D call has
dropped a glTexImage2D on level 0 of another cubemap face that should be
'initialising' it. What we do is just upload all faces. Initial contents will
then replace the contents.
* However, this assumes there will be initial contents to replace. If we only
have a set of cubemap uploads because the cubemap was uploaded within the
captured frame, we can't do this replicate each time or the last face uploaded
will be splatted across all. Instead we check to see if this is the first
glTexImage2D call on a level, and only replicate in that case.
By default RenderDoc saves captured frame thumbnail image as JPEG which
is lossy compression and makes it difficult to use as a reference image
for testing. Added an option to save thumbnails in different formats.
In order not to change the binary serialization format of .rdc files, if
the thumbnail format is not JPEG, a default JPEG thumbnail is still
saved in the file header as before, while the actual thumbnail is saved
as an additional chunk in the binary sections list. Older versions of
RenderDoc will just ignore this section and still use the legacy JPEG
thumbnail.
Change-Id: Icbf4fbd629719b49868fb785a656f6c7c9946ef9
When resampling thumbnail image during extraction, the math logic
resulted in various rounding errors causing wrong rows/columns of
pixels to be sampled.
Replaced floating point math with integer arithmetic to remove the
rounding errors and produce exact copy of stored thumbnail when no
resampling is needed.
Change-Id: Ic80987f646c5695b4a6755bd8e7110a1a4f675b4
baldurk