Created attachment 189101 [details]
Screenshot

I cannot reproduce this in my local master build. I updated my build this morning so maybe this has been resolved in today's nightly build?:

Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 7d745697eec8dc5702eb0ebaa8c4b5122c31edab
CPU threads: 8; OS: Mac OS X 12.6.8; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

OK. I can reproduce this bug in this morning's (23 August 2023) nightly master build.

I will see if I can figure out what is happening. Maybe there is some code that is only being compiled in debug builds?

Created attachment 189105 [details]
Snapshot of scaling in font work

(In reply to Patrick Luby from comment #4)
> Created attachment 189105 [details]
> Snapshot of scaling in font work

I am also seeing scaling of some semi-transparent gradients in the above screen snapshot of the following document:

https://bugs.documentfoundation.org/attachment.cgi?id=188661

(In reply to Patrick Luby from comment #5)
> 
> I am also seeing scaling of some semi-transparent gradients in the above
> screen snapshot of the following document:


That gerrit change from mikekaganski (https://gerrit.libreoffice.org/c/core/+/155952)
has a very interesting failure in it:

C:/lo/src/core/vcl/qa/cppunit/skia/skia.cxx:409:`anonymous namespace'::SkiaTest::testDelayedScaleAlphaImage
equality assertion failed
Expected: 60
Actual  : 20


Which indicates that sometimes scaling is not occurring when we want it to - it might be easier to track down and fix that failure first, since the unit test is much more contained.

(In reply to Noel Grandin from comment #6)
> Which indicates that sometimes scaling is not occurring when we want it to -
> it might be easier to track down and fix that failure first, since the unit
> test is much more contained.

Good idea. I have seen some "if (delay...)" type of calls in vcl/skia/gdiimpl.cxx so I'll start there.

I am also doing a clean build with only --endable-dbgutil and without --enable-debug like the nightly builds do to see if I can reproduce the bug in a local build. I have this feeling that one of more of my recent fixes only work in an "#if OSL_DEBUG_LEVEL > 1" block.

(In reply to Patrick Luby from comment #7)
> I am also doing a clean build with only --endable-dbgutil and without
> --enable-debug like the nightly builds do to see if I can reproduce the bug
> in a local build. I have this feeling that one of more of my recent fixes
> only work in an "#if OSL_DEBUG_LEVEL > 1" block.

Update: I can reproduce this is a local master build by *not* using both of the following configure options:

--enable-dbgutil
--enable-debug

If one, or the other, or both are used, the bug does not occur. If neither is used, the bug occurs.

I will investigate further.

It's fine on Windows (with daily build from 9 day's ago)
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 518fa99dd7693d64a53e404a065090aedc0002b1
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

No issue on Windows with
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c9916d9be9c060d43fc063b76d70629162650fea
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

So - for now - macOS specific

(In reply to Telesto from comment #10)
> So - for now - macOS specific

That is good to know. After some experimenting, this bug appears to be caused by Retina window scaling. If I force non-Retina window scaling in Skia using the following command, the bug does not occur:

export SAL_FORCE_HIDPI_SCALING=1

So, my current theory is that this is another case of issue https://bugs.documentfoundation.org/attachment.cgi?id=188792.

(In reply to Patrick Luby from comment #11)
> (In reply to Telesto from comment #10)
> > So - for now - macOS specific
> 
> That is good to know. After some experimenting, this bug appears to be
> caused by Retina window scaling. If I force non-Retina window scaling in
> Skia using the following command, the bug does not occur:

Well, I use a lodpi screen for my Windows environment...

(In reply to Telesto from comment #12)
> Well, I use a lodpi screen for my Windows environment...

No worries. I still think that this is a macOS-only bug because macOS is the only platform that has two pixel sizes in each image i.e. for Retina displays each 1x1 pixel on the screen is really 2x2 hardware pixels.

Apple decided at some point years ago that they would keep the size of a pixel the same as non-Retina displays in their software APIs and the extra resolution that a native bitmap can hold is hidden. Like LibreOffice, Skia goes through a bunch of extra code on macOS to preserve the hidden higher resolution bitmap as it is easy to accidentally downscale a bitmap.

It is in this code where the bug is occurring. I have a patch that I am still testing:

https://gerrit.libreoffice.org/c/core/+/156022

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/462f1c43cc97eb5c13343f285516702aa0c47a8d

tdf#156866 use mSize instead of mPixelSize for inverted surface

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I have committed a fix and the fix should be included in tomorrow's (25 August 2023) nightly master build.

Looking good again in

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e15bf7363adb20c77aee51e09b6f2604d741619b
CPU threads: 4; OS: Mac OS X 13.5.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Thanks Patrick.