PNG Texture2D compression format for BlazorGL?

[dtaylorus]

The content pipeline produces huge xnb files for textures by default, which is not ideal for a web game. For example, I have a 700K texture that becomes a 16MB xnb that has to be downloaded on first load, which is not great on a mobile device.

The pipeline supports some texture compression options, but they are all lossy and in my case my game cannot tolerate this because the textures have data used by shaders.

Ideally, I would like to use the PNG file format but this currently requires code changes to load content from a stream, which is a complication for cross-platform projects.

It seems like the ideal solution would be for the content pipeline to support PNG as an alternative compression format for textures so the differences between the content types on different platforms could be handled in the content pipeline rather than in platform-specific code.

@nkast Would you be open to this change? I'd be happy to implement it, but I don't want to spend time on it if you wouldn't accept the change.

[nkast]

That's a good feature, Adding a ColorPng TextureFormat that would decompress to Color on runtime.

There's also QOI format which has quick decoding compared to PNG. but worst compression ratio.
https://qoiformat.org/benchmark/

In our case a high decoding speed might be better that a high compression ratio.
Since everything is happening synchronously, we should consider the time we spend decoding PNGs,
is a time delay to request the next file.
If we spent 10ms to decode a PNG, on a 4G ( 150 Mbit/s),
at that same time we could had downloaded 187k for the next file.

Anyways, if you want to proceed -png or not-, I'd be happy to include it.

[dtaylorus]

The QOI format looks great and I could see using this for other platforms as well where lossless compression makes sense.

I have a hack in my current BlazorGL project that works well enough to release it but I will plan to come back to this for my next project and add the new ColorPng and ColorQoi formats.

[nkast]

Any one of the formats will be ok for now as a first PR to test it.

[nkast]

Some more thoughts on this...

xnb already has compression with the same characteristics as QOI, fast decompression, medium ratio. The net result might be equal.

PNG specialized in compressing images but with extra cost in decoding.
On BlazorGL we decode PNG with StbImageSharp. I am skeptical on how good its performance is.
As an alternative we have PngReader at /Platforms/Utilities/Png/PngReader.cs

Another idea is to extend the compression algorithm in XNBs (Lz4), and use the build in compression libraries on .net.
Those are very optimized and very efficient.
https://devblogs.microsoft.com/dotnet/introducing-support-for-brotli-compression/
https://ianqvist.blogspot.com/2014/12/net-compression-libraries-benchmark.html
https://www.linkedin.com/pulse/analyzing-python-compression-libraries-zlib-lz4-brotli-py-rs-av88c/

[nkast]

A quick test on compressing SpriteFont data.
(does not include the XNB header)

Compression	size	ratio
plainData	21682	100%
Lz4	6347	29%
brotli (optimal)	5308	24%
brotli (SmallestSize)	4241	20%

taking Lz4 as the baseline:

Compression	size	ratio
Lz4	6347	100%
brotli (optimal)	5308	84%
brotli (SmallestSize)	4241	67%

The Spritefont :

<?xml version="1.0" encoding="utf-8"?>
<XnaContent xmlns:Graphics="Microsoft.Xna.Framework.Content.Pipeline.Graphics">
  <Asset Type="Graphics:FontDescription">
    <FontName>Arial</FontName>
    <Size>12</Size>
    <Spacing>0</Spacing>
    <UseKerning>true</UseKerning>
    <Style>Regular</Style>
    
    <CharacterRegions>
      <CharacterRegion>
        <Start>&#32;</Start>
        <End>&#126;</End>
      </CharacterRegion>
    </CharacterRegions>
  </Asset>
</XnaContent>