The currently used svg icons which are installed in the hicolor theme folder are way too large and therefore take too long to render for their use-cases. Those icons are suppose to show up in application-launchers which usually should not exceed a required size of 512x512px where the normal usage would be something like 64x or 128px. Also those icon should not be that detailed and it should be possible to render them in less than 10ms using e.g. librsvg (currently like more than 200ms) 465K /usr/share/icons/hicolor/scalable/apps/libreoffice-base.svg 1,3M /usr/share/icons/hicolor/scalable/apps/libreoffice-calc.svg 624K /usr/share/icons/hicolor/scalable/apps/libreoffice-draw.svg 550K /usr/share/icons/hicolor/scalable/apps/libreoffice-impress.svg 142K /usr/share/icons/hicolor/scalable/apps/libreoffice-main.svg 659K /usr/share/icons/hicolor/scalable/apps/libreoffice-math.svg 142K /usr/share/icons/hicolor/scalable/apps/libreoffice-startcenter.svg 534K /usr/share/icons/hicolor/scalable/apps/libreoffice-writer.svg For reference https://github.com/LibreOffice/core/commit/250feedd8e50e5eb52682a194823567ba5287c60
I checked the LO svg files and they were 256x256 in size and a number of other svg files from other apps had the same dimension (e.g. gthumb.svg). It seems the main issue is how detailed the images are, which also causes the file size to be larger than any other image in the folder. So it would be good to reduce the detail of these images for when they are used in that folder, but the original svg should be retained in their original state for when they are needed elsewhere.
Just to clarify that with 512x512px I was referring to a non-scalable pixel-based image. Therefore the details should be adjusted/reduced for this target-size. The shipped SVGs are of course scalable and the internal pixel-size is irrelevant here.
Looking in /usr/share/icons/hicolor/, libreoffice provides raster icons for 16x16, 32x32, 48x48, 128x128, 256x256, and 512x512, which can be utilized by application launchers. So i checked the application launchers from different desktop environments to see what they utilized. 16x16: LXDE 22x22 or 24x24: Gnome 2, Mint Mate, XFCE 28x28: KDE 5 (all their icons are breeze) 32x32: KDE 4, Gnome 3 Launcher (might be different at different resolutions) 48x48: Unity Launcher 64x64: Unity 96x96: Gnome 3 Only Gnome 3 seemed like it was processing the SVGs as likely it was searching for raster versions in the 96x96 folder, but it only rendered them once and then cached the result. So how i see it is that we should include 22x22, 24x24, 64x64 and 96x96 raster icons in our linux packages so that launchers dont have to scale down larger raster versions (this is happening in Ubuntu Mate - https://bugs.launchpad.net/ubuntu-mate/+bug/1551029) and newer full screen launchers dont have to render the svg.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
IIRC the macOS app launcher packs images with different sizes up to 256px. Don't see much benefit from messing up with the few bytes. => WF
We agreed in the design meeting to add 24, 64, 96px icons. Andreas, can you do this?
where should the svg files be stored?
(In reply to andreas_k from comment #7) > where should the svg files be stored? If you are looking to trim down the details of the svg files which Rico was suggesting, then these svgs files are found in the apps and mimetypes folders in /core/sysui/desktop/icons/hicolor/scalable/, so you can overwrite them there. But what we decided in the design team was to add 24, 64, 96px pngs icons into new folders in /core/sysui/desktop/icons/hicolor/, so that launchers wont try to use the svgs as we provide the rasterized version of the size they request.
can I make in /core/sysui/desktop/icons/hicolor/scalable/16x16 /core/sysui/desktop/icons/hicolor/scalable/32x32 /core/sysui/desktop/icons/hicolor/scalable/48x48 /core/sysui/desktop/icons/hicolor/scalable/128x128 /core/sysui/desktop/icons/hicolor/scalable/256x258 and add there the svg files? cause they are all in wikipedia but didn't find the svg files in the LibreOffice source code which is strange.
Subfolders under scalable arent useful, so if there are svgs available for 16, 32, 48, 128, and 256, add them to the corresponding hicolor subfolders along with the pngs.
App icons: shrink svg files to a minimum https://gerrit.libreoffice.org/#/c/47201/ TDF#98141 add svg file for all app icons in all sizes https://gerrit.libreoffice.org/#/c/47220/ shrink the scale app icons and add all available svg app icons for the different sizes.
andreas kainz committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=61be109b1c10df3ddbb27f2a398b121a7c977f30 tdf#98141 add svg file for all app icons in all sizes It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
See <https://cgit.freedesktop.org/libreoffice/core/commit/?id=a648c07de904c993daae71a27f2b4c4ebc2ece3b> "Include new .svg icons in freedesktop-menus.spec" build fix. But is the change from comment 12 really useful? What benefit does it bring to complement existing {gnome,hicolor}/<NxN>/{apps,mimetypes}/*.png with corresponding {gnome,hicolor}/<NxN>/{apps,mimetypes}/*.svg?
andreas_kainz committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6ec4b1d0d4592a1e3c36151a062bd713a7939d14 Revert "tdf#98141 add svg file for all app icons in all sizes" It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.