You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
We're not correctly supporting
ContentTypeWriter.ShouldCompressContent
on: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 obeyShouldCompressContent
which it does not:https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework.Content.Pipeline/Serialization/Compiler/ContentWriter.cs#L147
The text was updated successfully, but these errors were encountered: