Monogame: Support ContentTypeWriter.ShouldCompressContent Correctly

[tomspilman]

We're not correctly supporting ContentTypeWriter.ShouldCompressContent on:

• SoundEffectContentWriter
• Texture2DContentWriter
• TextureCubeWriter

I know that XNA skips compression on sound effects compressed with MSADPCM... not sure about texture content.

The idea behind this API is to avoid extra overhead of generic compression formats (XNA used LZX and MonoGame uses LZ4) on content that is already significantly compressed. Otherwise at content loading time you do alot of extra CPU work to decompress it to only gain a tiny percentage of space.

Ideally we would test different sound effect and texture XNBs with and without compression to decide if compression is worth it in those cases. Like i don't remember if a texture already in a DXT format gains all that much when LZ4 compressed as well. If we gain less than 10% or 20% disk space it is arguable that we shouldn't compress those XNBs.

Also we need to fix ContentWriter to correctly obey ShouldCompressContent which it does not:

https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework.Content.Pipeline/Serialization/Compiler/ContentWriter.cs#L147

[tomspilman]

@KonajuGames - I think you did work on our LZ4 compression before, so you might want to see this.

[KonajuGames]

Yeah, I can take care of this. I've got a good understanding of the systems behind this.

[KonajuGames]

Interesting topic for thought. The XNA documentation states "The automatic compression algorithms do not compress source data that is small in size—less than one disk sector." (assuming 'disk' is a HDD). At the time XNA 3.5 and 4.0 were developed, HDD sector sizes were 512 bytes. Starting in 2009, becoming more widespread in 2010 and becoming mainstream in 2011, HDD sector sizes were expanded to 4096 bytes.

Defining it on a disk sector made sense back then, because I/O read time had a greater effect than they typically do now, and reading a 10-byte file or a 500-byte file took the same amount of time because it has to read an entire sector regardless.

We should apply the same conditions, but I think it would make sense to use the more typical 4096 byte size as a minimum for compression.

[tomspilman]

I think it would make sense to use the more typical 4096 byte size as a minimum for compression.

That sounds reasonable to me.