Optimize quality and performance

[jstcki]

JIMP is pretty neat because it doesn't depend on some binary (makes it easy to run anywhere) but performance degrades quickly with many images.

Also, the resized image quality could be better (noticeable when scaling down 1px lines in transparent PNGs).

These problems could potentially be remedied with using another library/binary. Maybe add a configuration option for the 'engine'.

[jstcki]

See http://sharp.dimens.io/en/stable/performance/

[jstcki]

JIMP now actually supports different resizing algorithms: https://github.com/oliver-moran/jimp#resize-modes

[gabrielbull]

Yeah, performance goes down the drain as soon as you use this library in a real world scenario. I added a few images already the dev server takes 20x as long to boot up, I'm afraid to add anymore image.

1. Is there a way for a loader to do on demand loading when running the web pack dev server or do all images need to be processed before web pack can run?
2. Can we implement caching between dev server sessions to reduce that boot time?

[sidonaldson]

I've had to pull this from my project as it's killing the build. I have about 30 large jpgs that it tries to generate srcset for and it just hangs. Sadly unusable in production at this time. Shame as it's the better one

[jstcki]

Yeah, probably a sharp "adapter" would be quite useful. Any thoughts on if this should be optional (use sharp when it's present, otherwise fall back to JIMP) or if we just should drop JIMP because it's too slow in practice?

@sidonaldson how large are your JPGs?

FWIW, we use it in production to generate ~200 regular sized JPGs and PNGs, and the build takes around 5min on Codeship (including all other assets).

[langri-sha]

👍 for retaining JIMP, for future users which would like to run Webpack compilations in the browser and use responsive-loader there.

[langri-sha]

I have a dirty WIP branch that's using sharp in case anyone wants to test https://github.com/langri-sha/responsive-loader/tree/sharp. I have about 50mb of images being processed and on my Intel m5 it used to take about 4 minutes with jimp and now it's down to ~15s.

Travis CI will need some tweaking to get sharp built inside their node-js container.

[jstcki]

Closed via #29