* 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
If "adb install" command is used with "-g" flag, we may get java.lang.SecurityException on some devices because granting runtime permissions at installation time is only allowed for system apps (however we can enable it in the device's Developer options menu).
Also, pulling APK from /data/app/ may be restricted. We can workaround by copying the APK to a directory which we can access then try to pull the APK from there.
It is possible to read a large value into compSize, and consequently read
a large number of bytes into m_CompressBuffer, which can only hold 64k,
which would lead to a crash.
baldurk