[hug]

So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library.

In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart, despite the fact that every NASCAR team in the world uses one, and my go-kart drives just fine. I should go tell the NASCAR teams that fuel pumps are a terrible idea. I clearly know something they don't.

[pier25]

You are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.

[hug]

I am most assuredly not missing the point. Your use-case is not my use-case.

I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else.

Also, my go-kart also gets more miles to the gallon than NASCAR team cars.

[pier25]

> I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else.

Fair point but you have to admit that is a very niche use case.

Have you compared the execution to native performance? Even decoding a 50MB JPEG in Chrome with turbojpeg is going to be a hard pill to swallow.

[hug]

I do know it's a niche use case. And I for sure wouldn't recommend that every man and his dog use the polyfill. I'm not even sure it's right for the scenario I'm thinking of. But I can definitely contrive a case where it is.

I haven't benchmarked this specific thing, because I've never used it. But I might, because it sounds like a fun thing to do.