... unless you wanted that in the summary?
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 16 2020
Updated diff. It's setting the quality now, and added a brief comment.
Ping! I think this got buried. Unless someone else is testing this?
Jan 14 2020
It's not overly scientific, but with this little fix, it can gen ~10 thumbnails a second on my system (1.6 Ghz pentium, ~10MP). This seems on par with png files of a similar size. As far as I can tell, there is not a super huge performance decrease. Please note, I use a potato.
Less is more, removing the line appears to be a solution as well. Assuming QImageReader uses sane defaults.
Okay, removing the line appears to have a similar effect to what I already did. I checked over on the imagecreator.cpp file, which appears to handle the thumbnailing of most other image types, and despite also using a QImageReader object, it does not call setQuality. My best guess is that QImageReader uses a sane value by default, and the imagecreator.cpp class lets that ride, ergo good thumbnails. I have no clue why this was set here, nor why it was set to 0.
I'm going to delete that line and see what happens.
It appears to me that the setQuality() function is meant to, in this use case, to simply decide what downscaler to use. Higher values mean better quality downscaling.
This does not affect the size of the created thumbnail, as all thumbnails are stored as png images regardless of source image type. This simply allows the thumbnailer to downscale the image without the artifacting displayed in the screenshots. I have checked and double checked that the resultant size of the thumbnails remains unchanged.