The png form is a lossless compression format. There is no additional cost when reading a png image with the maximum compression force (except a few memory which is already provided by the hardware requirement of LibreOffice). The compression force should be the maximum compression (9) by default. Even with weak hardware, the global benefit would go to the maximum compression force since the file size would become smaller. Once the file size is smaller, then the computer is faster each time the document is saved. On the other side, the user will encounter only one time the the additional effort when resizing a png image with the maximum compression force.
For png, the compression window could provide a "use 256 indexed colours" checkbox instead of the compression force. This would be an actual "quality" parameter.
Do not inflate the bugs.
Personally I'm glad this is set to Won't Fix because I prefer to set all my PNG compression settings to 1, not 9. The higher the compression, the more work to process that compression when a graphic loads, and I'm not lacking for disk space that I need high compression settings.
(In reply to xordevoreaux from comment #3) > I prefer to set all my > PNG compression settings to 1, not 9. The higher the compression, the more > work to process that compression when a graphic loads, and I'm not lacking > for disk space that I need high compression settings. This article tells that a deflate archive (png compression method) is read faster with the 9 force than with the 1 force : https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf I you want your images to load faster, maybe you could try to set the 9 png compression force.
When I save with compression 1 with a PNG, it's faster to complete than compression 9, and if using Save as Images... extension, huge difference across several slides, compression 9 can take a while. It would follow that the tighter compression (9) would take longer to achieve for requiring more to calculate. The 'Compression level' setting when saving PNG files determines the final file size of your image and also affects how long it will take to save. The highest compression rate (0 is lowest and 9 is highest) will make the smallest file, but it will also take the longest to save. But you know what, there's all kind of things I have to work around to make LO work for me, so do whatever, I'll compensate as usual.
(In reply to xordevoreaux from comment #5) > When I save with compression 1 with a PNG, it's faster to complete than > compression 9 Yes it is. > The > highest compression rate (0 is lowest and 9 is highest) will make the > smallest file, but it will also take the longest to save. No, that's wrong. The mistake you made is that the image compression isn't performed each time you're saving the file. Once the image compression is done, if the image isn't changed, then the file content is just stored into the jar archive of the ODF file. The more the png compression is, the smallest the file is and the fastest the ODF file is saved. On computer with low hardware, maybe we should think about setting the 9 PNG compression force by default.