Preview providers should take maxX and maxY into consideration

[oparoz]

Problem

The interface includes maX and maxY for a reason and yet, none of the providers use it.

A 5000x5000, 140MB TIFF is currently being converted to a 5000x5000 50MB PNG.
Fortunately, it will soon be possible to avoid multiple roundtrips to ImageMagick (via #13674) , but each resizing request of that 50MB PNG is still going to take some time (and waste memory) and that will only partially be fixed once #8196 is implemented.

Solution

Make sure preview providers take maxX and maxY into consideration when generating previews. With #13674 in place, each provider should only be called once.

I'm going to fix Bitmap, but the other providers should be fixed as well.

• Bitmap
• Image
• Txt
• MP3
• SVG
• Movie

[oparoz]

Job done for all files using the bitmap preview class: #13635

[oparoz]

Re-opening, as the Image provider is not taking the max dimensions into consideration

[oparoz]

Fix for all remaining providers is in #16382

[PVince81]

You tagged this as regression, so this worked before ?

[oparoz]

Yes, before the max preview, each provider would be queried for each request and thus provide a preview matching the asked dimension. Since they're now only use to generate the max preview, we need to make sure those previews keep the aspect ratio of the original image.

[DeepDiver1975]

@oparoz we can close this now that #16382 is merged? THX

[oparoz]

Yes, the API should now return the expected previews.

[DeepDiver1975]

Yes, the API should now return the expected previews.

awesome - thanks @oparoz for your contribution - very much welcome!