* 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