> I think that's sufficiently fast. (Keep in mind that a 4k screen is about 8.5mp.) How fast do you want your slideshow to be?

A modern iPhone can capture at up to 48MP. If the performance scales linearly with pixel count, that would put tapping on a thumbnail to the full size being ready at over half a second. That's going to feel laggy. Now you can throw storage at the problem and pre-compute a downscaled intermediate, sure, but that doesn't fix it when you send the photo to someone else or whatever.

And competitive phones are doing 200mp captures (which is stupid in its own right but phone manufacturers and doing stupid things, name a more iconic duo)

> How fast do you want your slideshow to be?

we're in 2026, 240hz screens are becoming common. Nothing in the end-user experience should take more than 3-4ms. My personal goal when developing is keeping things at at least 60FPS and ideally 120 when building the whole stack with ASAN / UBSAN / stdlib's debug modes.

For instance when looking at this the first thing I thought was to try to make an installation which permanently recurses the codec's application on itself at each frame, to give the impression of a constantly moving landscape. Impossible on a smaller machine if computing a single frame takes 150ms.

Think about the scenarios where people are viewing slideshows. If you're on a mobile device, that 150ms spent decoding each image is time where the CPU and/or GPU of the mobile device are running at full tilt, draining the battery. Suddenly applications that would normally be fast and efficient like a photo gallery app become laggy and drain your battery. Not great.