Created attachment 195603 [details]
Screenshot showing blurry icons

I tend to confirm the issue in question for

Version: 24.2.5.2 (AARCH64) / LibreOffice Community
Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59
CPU threads: 10; OS: macOS 14.6; UI render: Skia/Metal; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Version: 24.8.0.1 (AARCH64) / LibreOffice Community
Build ID: 6fd6cae02baed1e82d14ed2da1f2458092354dab
CPU threads: 10; OS: macOS 14.6; UI render: Skia/Metal; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: d671bceed0ba7195eae1e063d4a363074f8483a0
CPU threads: 10; OS: macOS 14.6; UI render: Skia/Metal; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

The icons in question seem to be or are a little bit blurry instead of crisp (and so maybe non-SVG?).

*** Bug 162265 has been marked as a duplicate of this bug. ***

(In reply to Sierk Bornemann from comment #2)
> The icons in question seem to be or are a little bit blurry instead of crisp
> (and so maybe non-SVG?).

This is not a bug in the LibreOffice code. Instead, this is a feature request to recreate the non-SVG icon sets. AFAICT, all of the non-SVG are very low resolution bitmaps. Upscaling a low resolution bitmap cannot increase resolution so the solution to this problem is to recreate any bitmap icons to be 2x wider and higher.

Until the icon creators (I assume most are volunteers) recreate their bitmap icons to have more pixels, this will not change.

That said, I did change the default icon set to an SVG icon set starting in the upcoming LibreOffice 24.8 release. Most SVG icons are expressed as shapes and text so they can be drawn at higher resolution so that release will also draw most SVG icons at higher resolution than in LibreOffice 25.2 and earlier.

@Rizal, could you have a look at your Sukapura to see if you are missing SVG for the affected icons?

=-ref-=
https://gerrit.libreoffice.org/c/core/+/166867 puts icon theme rendering on macOS over to the SVG flavor graphics

Not directly a solution here, but proposed icon theme packaging (mulit-resolution bitmaps and SVGs) of bug 148764 would move LO's UI forward cross platform and handle user display at various resolutions.

Regards the non-button icon graphics on the Start Center, IIRC those are already rendered from bundled SVG? Why would they be blurry at Retina 5K resolution?

(In reply to V Stuart Foote from comment #6)
> cross platform and handle user display at various resolutions.
Hmm, make that

s/handle/facilitate/  

as some refactoring would probably be needed to parse the packaging.

I don't think it is a case of missing icons because the The character highlight color and font color icons are crisp on the toolbar (see the top of the screenshot and compare the same icons on the sidebar).

(In reply to Faisal from comment #8)
> I don't think it is a case of missing icons because the The character
> highlight color and font color icons are crisp on the toolbar (see the top
> of the screenshot and compare the same icons on the sidebar).

That could be, Caolán had looked at it for similar for GTK3 backend for bug 151898, suggesting different handling between TB buttons and SB content panel buttons is a possibility--even if the SVG is available.

(In reply to Faisal from comment #8)
> I don't think it is a case of missing icons because the The character
> highlight color and font color icons are crisp on the toolbar (see the top
> of the screenshot and compare the same icons on the sidebar).

I now see what you describe. I am not familiar with that code but my first guess is that the sidebar is using the same font icons as the toolbar but it is downscaled to be smaller than the actual icon size.

So probably the solution in for the sidebar is to increase the size of the smaller buttons in the sidebar so that their icon has room to fit in the button without having to be reduced in size and losing more resolution. Not sure how to do that but maybe someone else can test my theory?

Side note: the font color icons in the toolbar that you describe as crisp look relatively blurry to me. That's where I got confused.

Created attachment 195612 [details]
Snapshot with Sukapura Dark + SVG icon set running LibreOffice 24.8 RC

Posting a snapshot of LibreOffice 24.8 RC with the improved resolution of SVG icons. Note: resolution is better in the sidebar but some resolution is still lost in sidebar icons that have been reduced in size.

Sidebar icons differ from those on the toolbar in case of Sukapura- the character highlight is with/without text. The screenshot in comment 1 shows the samer icon though.

SVG icons are rasterized depending on the DPI and we would have to create two sizes, if the toolbar is set to small and the sidebar to large. Tomaz, you know best.

(In reply to Heiko Tietze from comment #12)
> SVG icons are rasterized depending on the DPI and we would have to create
> two sizes, if the toolbar is set to small and the sidebar to large. Tomaz,
> you know best.

So I did some debugging and verified that the sidebar icons are using the same fix for SVG icons that I implemented for the toolbar icons: the SVG icon is rasterized to a bitmap that is 2x width and height.

How the fix for the toolbar SVG icons works is that the toolbar SVG icons are rasterized to "double sized" bitmaps and then drawn directly to a drawing surface to half the width and height. Since on macOS drawing surfaces hold 4 pixels for every one pixel, drawing a bitmap at half its width and height preserves all of the pixels in a "double sized" bitmap.

I would expect that the same behavior would occur with the sidebar SVG icons. But, unlike the toolbar icons, the "double sized" bitmap looks like it is downscaled back to half width and height somewhere *before* drawing. The LibreOffice code really doesn't handle the "macOS has 4 (really 2x2) pixels per pixel" behavior as it is unique to macOS.

So, I think my next step is to try to find where LibreOffice is downscaling sidebar icons before drawing. In other words, the "double sized" bitmap should be used to draw the icon but it looks like what is drawn is a downscaled copy of the "double sized" bitmap.

Created attachment 195686 [details]
Debug patch that disables drawing the color rectangle in the character color toolbar buttons

Created attachment 195687 [details]
Snapshot of sidebar character color toolbar buttons in sidebar

The top icons are a snapshot of LibreOffice 28.0 RC (zoomed in) and the bottom icons are a snapshot of my local build (also zoomed in) with the debug patch in attachment #195686 [details].

(In reply to Patrick Luby (volunteer) from comment #15)
> Created attachment 195687 [details]
> Snapshot of sidebar character color toolbar buttons in sidebar
> 
> The top icons are a snapshot of LibreOffice 28.0 RC (zoomed in) and the
> bottom icons are a snapshot of my local build (also zoomed in) with the
> debug patch in attachment #195686 [details].

So I found the code that causes the character color icons in the sidebar to be blurry: its ToolboxButtonColorUpdaterBase::Update() that adds the color rectangle at the bottom of the icon.

I disabled that code completely in my debug patch in attachment #195686 [details]. With that debug patch you can see the original, unmodified icons in the bottom of attachment #195687 [details] are much higher resolution.

I read the code in ToolboxButtonColorUpdaterBase::Update() and here is what I think is happening:

1. Before ToolboxButtonColorUpdaterBase::Update() is called, the correct SVG icon is rasterized to a "double sized" width and height bitmap.

2. Somewhere else in the LibreOffice code, the SVG icon is converted to a regular (i.e. not "double sized") PNG image that is saved in a disk cache.

3. ToolboxButtonColorUpdaterBase::Update() is called and it calls vcl::CommandInfoProvider::GetXGraphicForCommand() to load the lower resolution PNG file from the disk cache.

4. The lower resolution PNG file and the color rectangle are drawn to a drawing surface and a bitmap is extracted from the drawing surface. This new image replaces the higher resolution bitmap created in step 1 above.

I am not familiar with the PNG disk caching code so I'm not sure how this can be fixed. My first guess is that the PNG cache needs to either be ignored or should cache "double sized" PNG files. However, I have feeling that that would also require code to downscale the "double sized" PNG files in ToolboxButtonColorUpdaterBase::Update() and probably elsewhere in the LibreOffice code.

Application::GetDefaultDevice()->GetDPIScaleFactor(); in ImplImageTree::loadDefaultImage() maybe? See https://gerrit.libreoffice.org/c/core/+/30339

(In reply to Heiko Tietze from comment #17)
> Application::GetDefaultDevice()->GetDPIScaleFactor(); in
> ImplImageTree::loadDefaultImage() maybe? See
> https://gerrit.libreoffice.org/c/core/+/30339

Unfortunately that is not the problem. That code has been changed quite a bit since that patch but I was able to double the scale with the following debug patch. That caused lots of images to double in size, but did not change the size or resolution of any toolbar or sidebar icons.

One new piece of information: I found that the icon disk cache is caching "double sized" images (they are in a "200" subdirectory in the disk cache) so I will look at forcing icon image loading from the "icon scaled 200%" disk cache. Once I figure that out, then I can scale down to 100% size when the bitmap retrieved from the disk cache is actually drawn:

diff --git a/vcl/source/image/ImplImageTree.cxx b/vcl/source/image/ImplImageTree.cxx
index f565461f8607..4dae13736252 100644
--- a/vcl/source/image/ImplImageTree.cxx
+++ b/vcl/source/image/ImplImageTree.cxx
@@ -170,6 +170,7 @@ void loadImageFromStream(std::shared_ptr<SvStream> const & xStream, OUString con
 {
     bool bConvertToDarkTheme = rParameters.convertToDarkTheme();
     sal_Int32 aScalePercentage = rParameters.scalePercentage();
+    aScalePercentage *= 2;
 
     if (rPath.endsWith(".png"))
     {