Gzip compress IDR_AUDIO_SPATIALIZATION_COMPOSITE.

Gzip compress IDR_AUDIO_SPATIALIZATION_COMPOSITE.

This WAV file is an HRTF database needed by WebAudio.  It's the largest
single resource in Resources.pak on Android.  Applying gzip compression
shrinks it from 240k to 140k (still the largest resource, even then).  The
tradeoff will be worse WebAudio startup time and RAM usage, but WebAudio
is rarely used so it's more important to optimize for global cost on all
users (in this case, APK size).

BUG=655429

[aelias_OOO_until_Jul13, 2016-10-13 01:17:49]

Description was changed from

==========
Gzip compress IDR_AUDIO_SPATIALIZATION_COMPOSITE.

This WAV file is an HRTF database needed by WebAudio.  It's the largest
single resource in Resources.pak on Android.  Applying gzip compression
shrinks it from 240k to 140k (still the largest resource, even then).  The
tradeoff will be worse WebAudio startup time and RAM usage, but WebAudio
is rarely used so it's more important to optimize for global cost on all
users (in this case, APK size).

BUG=
==========

to

==========
Gzip compress IDR_AUDIO_SPATIALIZATION_COMPOSITE.

This WAV file is an HRTF database needed by WebAudio.  It's the largest
single resource in Resources.pak on Android.  Applying gzip compression
shrinks it from 240k to 140k (still the largest resource, even then).  The
tradeoff will be worse WebAudio startup time and RAM usage, but WebAudio
is rarely used so it's more important to optimize for global cost on all
users (in this case, APK size).

BUG=655429
==========

[aelias_OOO_until_Jul13, 2016-10-13 01:17:49]

aelias@chromium.org changed reviewers:
+ rtoy@chromium.org

[aelias_OOO_until_Jul13, 2016-10-13 01:17:59]

Hi rtoy@, PTAL.

[aelias_OOO_until_Jul13, 2016-10-13 01:20:44]

The CQ bit was checked by aelias@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-13 01:20:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[agrieve, 2016-10-13 01:34:24]

On 2016/10/13 01:17:59, aelias wrote:
> Hi rtoy@, PTAL.

I'd guess this breaks whatever the resource is used for The gzip support was
changed to no longer be automatically uncompressed when requested here:
https://codereview.chromium.org/2149323003

[agrieve, 2016-10-13 01:38:32]

On 2016/10/13 01:34:24, agrieve wrote:
> On 2016/10/13 01:17:59, aelias wrote:
> > Hi rtoy@, PTAL.
> 
> I'd guess this breaks whatever the resource is used for The gzip support was
> changed to no longer be automatically uncompressed when requested here:
> https://codereview.chromium.org/2149323003

Just remembering as well - one of the reasons we held off targeting this one
before was that even with ResourceBundle automatically decompressing it, you'd
need to update ContentClient to use the RefCountedMemory version of
LoadDataResourceBytes rather than the StringPiece one so that it would actually
free the memory.

Certainly like the idea of using flac, which would avoid these issues.

[aelias_OOO_until_Jul13, 2016-10-13 02:12:32]

Yeah, this WAV file ends up in DecodeAudioFileData(), so if I'm reading things
correctly, we could replace this resource with any other FFMpeg-supported audio
codec (including Flac) and things would "just work".  That seems cleaner than
trying to make gzip work, so closing this.