We got this feedback regarding server-side image resizing:
Just makes me wonder - the very strong comprerssion and low quality (both settings) are probably defaults from many years ago when bandwiths and data plans were quite low, processing power and RAM on Servers and devices were low too.
Wouldn’t it maybe be good to change these values to new higher quality defaults as todays bandwiths, data allowance and processing power of devices and servers are much better now?
I know we had a few complains over the years regarding this, and I assume many XWiki instances are disabling the server-side image resize using:
I honestly never been a fan of this feature which cause quite a few problems (default quality just being one of them). But everytime I mention the idea to disable it by default, I’m told it’s obviously needed.
But if we disable it by default, some stuff will need to be fixed for sure as we often notice a few UI issues every time we disable that (mainly code assuming that the source image always have the right size and don’t set it explicitly in the <img>).
OTOH doing it server-side means using the server CPU and if you have lots of queries asking for that, you’re impacting the server’s performance globally. And thus:
Could actually be the opposite, i.e. that the page would render faster if the computation was one client side (Since doing more CPU work server side makes it slower and that slowness may not compensate the additional time taken to transfer the full image).
I’m playing the devil’s advocate here since, without data, it’s hard to know what is the truth.
This is client side memory I think.
Definitely. However, the problem is now (and has been for a lot of time). So I’m more -1 to continue to not address it and if to address it it means setting rendering.imageDimensionsIncludedInImageURL = false by default while waiting for a better solution, then I’m definitely +1 (users can always turn that on again if need be, for ex it could be a config option indicated in the Performance tuning guide in case you run into perf issues).
Said differently, I think quality trumps performance for a default XWiki instance.
I expect mainstream browsers to be optimized for this, since they have to do it often. Copilot tells me it starts to become an issue, especially on mobile devices, with images above 8 megapixels (4k resolution). Do you think it’s common for XWiki users to upload large image files (8MP/4k)?
When not cached.
My worry in this case is that the quality loss is noticed by everyone while the performance boost is not needed by everyone (most won’t notice it).
Aren’t we saying the same thing? I’m proposing that we use by default the setting that provides the highest quality and that if performance becolmes a problem, we leave it to wiki admins to change the setting (and document it under our Performance doc page).
Yes. Standard mobile phone cameras have 12MP I think. Non-technical users have no idea how or when to resize an image, they will just upload an image they got from a camera, and then you have a 5MB download for a thumbnail-sized image. So, no, we shouldn’t disable server-side resizing by default, -1 for that. We should ensure that we use appropriate quality settings, and we could decide to only serve certain image sizes and thus partially rely on client-side resizing. We could also decide to generate these fixed image sizes (I’m thinking about something like 64x64px, 128x128px, 256x256px, 512x512px, 10124x1024px, 2028x2048px, but we should probably check what other software does) when the image is uploaded, storing them permanently instead of generating them on the fly at least for the most recent version of an attachment. Or, alternatively, still generate them on the fly but store them permanently - I think this is what Nextcloud does by default.
The idea here is to start doing something about it. Users have been complaining for years about this issue. What you suggest seems to take time and not on any roadmap. Would be good to have something for 18.5.0 final and stopping pushing the issue forever.
I asked an AI to perform a quick search for me and apparently, 75-85 are good quality/size tradeoffs, Nextcloud uses 80 and according to this article, WordPress uses 82. I guess we could go with 82?
I’m more in favor of resizing on demand. We are already caching the result AFAIK.
This is inline with what I usually do: resize server-side to a dimension slightly bigger than what I need client-side, then let the browser resize to the final dimension. This would also help with caching: we would cache (and serve) only some predefined dimensions. When we receive a resize request we check what is the first predefined dimension bigger than what the client asks for, and use / cache that value.