So recently I made another minimalist tool for myself. The first 4 bits are two chars to dictate the size of the image. The rest after that is all pixel data. (Now I am interested in options to make gray images which are 3 bytes less per pixel, :point:)
To test it out, I weighted it against TWL’s PNGDecoder. Each texture was loaded into a byte buffer. I did 200 passes and stored each TextureData thereof into an ArrayList.
Ignore the 0,1 1,0 they seem like an issue, they’re not.
Some things I noticed…
- The first call to load a texture is always the longest with a big overhead for some reason > probably caching or something? Like 12-24ms for a 100x100x4 pixel image. I loaded my .mx file (idk) and added it to an arraylist of data (which is the majority of its cost) at 89-93ms. While Png decoder ended up with 310ms.
- Loading a PNG using twl’s pngdecoder is strictly 60% slower than loading straight pixels. Yet I could get like 1.9 kilos with png (say that, but it also says its 4.0kilos) when storing the image straight up would take 40kilos plus two chars.
So I guess I suggest to myself to keep the MX file format and use a PNG unpacker system for distribution.
I switched over to MX and I got a cool 500-700ms performance boost!
I don’t even know about texture compression via Driver/OGL yet, which I’d imagine that would be faster?