Just to keep a track of the task.
We store images as jpg or png (erase, paintings, lang...). It can make sense to convert them to webp to gain some space without losing too much in quality.
For lang, it may be more tricky to update the external dataset. If it allows to gain "enough" (to be determined :)), maybe create a rcc with a new name for the new versions and at some point, delete the older?
For lang, we go from 59.7Mo to 40.2Mo with a conversion of all png with no loss (magick $f -quality 100 -define webp:lossless=true $f.webp), so for me, it's a go :).
For the jpg, if we don't apply any loss, we lose space, so not good. Same as for erase images, we would need to check if we want to compress them with a bit of a loss or not.
Note: I can implement the code for the lang switch and the creation of the rcc. If we decide to go with no loss, I can also do the conversion.
I already started working on it, but it takes time as I also replace some photos in some activities (currently in categorization especially, it's a bit long but soon finished).
In most cases, resizing not lossless with quality 90 is OK and already saves some space. For other cases like erase activity images, if we replace those with higher resolution images, they'll probably need to be compressed with quality 50 or 40 to have an acceptable size.
For lang, I've also started to take a look, and I think I'll take the occasion to scale-up and process the images so they will also look better on high resolution screen, before converting to webp. I'll ping you at that time to do the code switch and creation of rcc (and yes, as you said, it'll need to be a new rcc name, so we can keep the one with .png untouched for old versions).
All done (or almost, still waiting for the erase images from Karl, who is still working on it).
I've tested locally with generated words.rcc (which I've also updated with new images for current/previous versions) on gcompris 2.3, and the new words-webp.rcc with current master/stable branches, all seems to work good.
Only remaining issue I've found, is that I also had to manually change my wordset config in the config file (which was wordset=data2/words/words.rcc , and so I've changed it to wordset=data2/words/words-webp.rcc).
If you can please take a look to do that change automatically.
Also If you can please do the following:
-upload the updated words.rcc and the new words-webp.rcc to cdn.kde.org/gcompris
-update the scripts in gcompris-data to generate words-webp.qrc, and the README.md there to explain that we now use the words-webp.rcc and that the words.rcc is kept for now for old version (mostly useful for some distribution which ship gcompris-data as distro package).
-double-check on your side if all is good too, in case I missed something important
Looks good to me, I tested a few activities and didn't noticed any bug. There are still some png (but not big files so we won't gain much by converting them to webp):
src/activities/hangman/resource/fog.png
src/activities/memory-sound/resource/Tux_mute.png
src/activities/memory-sound/resource/Tux_play.png
src/core/resource/aboutkde.png
src/core/resource/arrow.png
src/core/resource/gcompris-icon.png
src/core/resource/gcompris.png
src/core/resource/star.png
If it's not needed, we can close this task as done.
I've updated the script and code to switch to the new one automatically. The only "issue" we could have is that if people disabled automatic updates and update the GCompris version, there is no text telling them the wordset is available (it was not the case before, so it would be a new feature).
Thank you!
Yes the remaining png files are intentional: fog.png was actually bigger when converted to webp lossy with quality 50, Tux_mute/play will need to be updated to new images when I work on updating the graphics for this activity (and as there's no big gain from converting them I prefer to keep them png for now), and the images in core/resource I prefer to keep them lossless so webp is probably not relevant for those.
I've tested the automated switch, all is good. For the "issue" you mentioned, as automatic update is the default setting, I think it's ok to keep as it is now... And anyway, for people with automatic update disabled, to have a way to tell a new wordset is available would require to connect to the server to check it, which would defeat the "no-auto-server-connection" part of this option, so I think we should not do it.
Closing the task as Resolved :)