ZDoom

Performance comparisons show that the old library and stb are both roughly 20% slower than Turbo. So the old code is definitely not worth keeping anymore.

What's more interesting is the viability of Libjpeg-Turbo. Yes, it is 20% faster in pure image decoding, but the image decoding is only half the time needed to upload the texture, so in the end we got only marginal savings conpared to stb-image.

Graf Zahl wrote: ↑Sat Sep 02, 2023 2:22 am By comparison, JXL adds 5 MB and AVIF at least 2MB, but only if we hack the library not to include suff we do not want, otherwise it's 12 MB. And source code size for these libraries is HUGE.
Quite a difference, actually, and I have a feeling this decoder bloat really won't help these two formats.

I am not really surprised. These formats get ever more complex as performance of computers increases and that comes with more code being needed most of the time.
But it also means that these formats will never get the universal support that makes JPG and PNG quasi-standards for image distribution.

I think these formats are a couple decades too late... The space savings would have been huge back in the dial up days, or even during the early days of broadband. Today bandwidth is plenty. Saving 30% on an image that takes a tenth of a second to download... what's the point? Now if we're talking video it's a completely different matter.

The point of these formats is not saving space but better compression quality.
The difference between JPG und WebP is already massive if you magnify the image, and these more recent compression algorithms leave even less artifacts.

What gets forgotten by the developers is that it must be dead easy to add support for the decoder libraries, and both AVIF and JXL comprehensively fail on that regard. WebP did it right by providing a self-contained and compact library that is relatively painless to add to a project, the other two definitely are not.

Does this recently-discovered vulnerability affect GZDoom, now that it has Webp support, or is it just a browser thing?

Yes, it does, and it has already been patched at least for vcpkg users by rolling to a new commit. Anyone who compiles their own libwebp library must use the post-patch version of libwebp or the vulnerability will still affect them.