Quote Originally Posted by NM64 View Post
First off, a quick unrelated question - any idea if Ultimate Edition renders output audio with 16bit, 24bit, or 32float bit depth? (I can't do the audio recording test that I previously did with Ren'Py to test audio bitdepth output since it's my impression that Ultimate Edition doesn't support lossless audio codecs for background music currently)
8 bit integer, 16 bit integer, 24 bit integer, 32 bit integer, and 32 bit float appear to be supported when using WaveSoundBuffer. This can be specified when using the "-wsbits" command line argument. See the reference for this command line argument: https://krkrz.github.io/docs/kirikir...Line.html#id37

This won't apply when using libmpv for playback.
Quote Originally Posted by NM64 View Post
Anyway, I just found out that JPEG XL includes the lower-resolution progressive-loading function that originated from FLIF that I was a big fan of. Since I know that Alyinghood was at one point looking into using JPEG XL in-place of our existing lossless WebP, I'm wondering if this lower-resolution progressive-loading function couldn't also be used in-conjunction with his elusive higher-quality-than-960p/1200p-resolution whereby you could save disk space by only including a single, ultra high resolution lossless(?) art asset in JPEG XL and then have the engine itself decode lower resolution versions when the display resolution requires it, thereby allowing lower-end systems to not be bogged down by ultra high-res art assets and reducing overall file size by not needing to include separate high-res and ultra high-res versions.

Heck I'm wondering if this could even be used as a way to make the "skip" function go even faster, e.g. decoding lower resolution versions of the art assets when in skip mode (perhaps a specific ratio like 0.5x size of the current program window size)

At the same time, JPEG XL apparently is very fast to decode which should also make it faster than the existing WebP let alone much faster than anything like AVIF (on a quad core system JPEG XL is supposedly a little bit faster than standard JPEG), so it's questionable if the hypothetical performance benefits I outlined above are even of any use (maybe with the exception of skip mode?).
JPEG XL makes heavy use of multithread and SIMD for speed improvements.
The performance and memory improvements when reading a downscaled version will depend on if JPEG XL can decode to a small buffer when doing that.