Created attachment 176623 [details]
2021-12-01 about window

Created attachment 176624 [details]
2021-12-01 impress templates

Created attachment 176625 [details]
2021-12-01 start center document preview

I think it can be an old problem with blurred images in macOS on HiDPI displays but today it's with Skia also

No issue with the build of today
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca
CPU threads: 8; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

but well I'm running a slightly older version of macOS

Which macOS are you on?

(In reply to steve from comment #6)
> Which macOS are you on?

Well the about screen tells this already ;-): I'm using 10.16. You're using 10.16.1

About will read "10.16" for any Big Sur version so if you are on macOS Big Sur 11.6 it would be 10.16 in LO about.

I manually change that info to the correct value "11.6.1" because LO is unable to do so.

This awkward situation is explained here: https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/

So you are running 11.6? You can see that info by clicking on the Apple icon top left > About this mac.

This would be an interesting finding if the issue was introduced with the 11.6.1 update while 11.6 works as expected.

(In reply to steve from comment #8)
> About will read "10.16" for any Big Sur version so if you are on macOS Big
> Sur 11.6 it would be 10.16 in LO about.
> 
> I manually change that info to the correct value "11.6.1" because LO is
> unable to do so.

Ah, non-practical

--
I'm so not up to speed with the version numbering of macOS (not), and even not to aware of the last major version. Anyhow, I'm currently running 12.01 Monterey.

So the version detection at LibreOffice being broken (again)

I cannot reproduce. Can you reproduce it with both software rendering enabled and disabled? This looks like a mixup of reading RGBA color values. Please provide more info about the HW relevant to display (resolution, color depth, etc.).

With this setting, the icons are highlighted in yellow (LO 1):
-Skia for all rendering (enabled)
-Force Skia software rendering (disabled)


When reinstalling to 7.4.0.0.alpha0 +, the error worked (LO 2):
-Skia for all rendering (enabled)
-Force Skia software rendering (enabled)
But I cannot repeat, I will look for an opportunity.

Additional Info:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 2934472ab888ebfe64a153984af2902fac63a7a0
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: Skia/Raster; VCL: osx
Locale: ru-RU (ru_UA.UTF-8); UI: en-US
Calc: threaded

Created attachment 176812 [details]
-Skia for all rendering (enabled) -Force Skia software rendering (disabled)

Created attachment 176813 [details]
-Skia for all rendering (enabled) -Force Skia software rendering (enabled)

Raising priority to high major since skia is now default for macOS in main (see https://qa.blog.documentfoundation.org/2021/12/10/qa-dev-report-november-2021/ General Activity 57.: "made macOS default to Skia").

High: this will affect all macOS users if I am not mistaken (or all HiDPI, which is all macs currently sold)
Major: although functionality itself is not broken, having all previews (start center, impress, ...) in unreadable state impacts usability

(In reply to steve from comment #14)
> High: this will affect all macOS users if I am not mistaken (or all HiDPI,
> which is all macs currently sold)

Given that I cannot reproduce, it's probably not all users.

> Major: although functionality itself is not broken, having all previews
> (start center, impress, ...) in unreadable state impacts usability

Can somebody check if it's the displaying of the previews that is broken or if the documents themselves already contain broken thumbnails? ODT/ODS/ODP documents are technically .zip files that can be unpacked and there is a thumbnail PNG somewhere in it.

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

I've asked a colleague who has an old iMac, and no luck either.

If somebody here would have the time and can do at least basic coding, vcl/skia/README has a section on debugging that describes how to find out which drawing calls are responsible, that could be useful here.

Lubos: which macOS version and mac are you unable to reproduce on and with which exact skia settings?

In reply to steve from comment #18)
> Lubos: which macOS version and mac are you unable to reproduce on and with
> which exact skia settings?

Based on bug 145843 comment 14 I would say:

Mac Mini M1:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 7e5af164b7d293dd410710bed411e1ca64bbecf7
CPU threads: 8; OS: Mac OS X 11.5.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Intel <-> Arm?

no problem in

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: b9c159361abd79862b30412c433fb355d63299e2
CPU threads: 4; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: threaded

I think it's a HiDPI+Skia problem on macOS because Denys checked it on HiDPI display

(In reply to Roman Kuznetsov from comment #20)
> no problem in
> 
> Version: 7.4.0.0.alpha0+ / LibreOffice Community
> Build ID: b9c159361abd79862b30412c433fb355d63299e2
> CPU threads: 4; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
> Locale: ru-RU (ru_RU.UTF-8); UI: en-US
> Calc: threaded
> 
> I think it's a HiDPI+Skia problem on macOS because Denys checked it on HiDPI
> display

I have the old mac mini 2014 with external 1920x1080 display

(In reply to Roman Kuznetsov from comment #20)
> I think it's a HiDPI+Skia problem on macOS because Denys checked it on HiDPI
> display

Can somebody who can reproduce it also try with remove desktop (VNC) to check if it can be reproduced that way as well?

> Can somebody who can reproduce it also try with remove desktop (VNC) to
> check if it can be reproduced that way as well?

Or try it with HiDPI temporarily disabled.

On MacBookPro14,3 (15", retina) system preferences > display set to scaled and selecting the very left option "Larger Text" does not change anything in regards to the problem. Start Center previews and other images still have wrong colors. Lubos if you want to take a look at this via remote connection just drop me an email.

Not reproducible with a 2018 Mac mini (Macmini8,1), running macOS Monterey, with or without HiDPI.

Could this depend on the GPU?
Whoever can reproduce it, please add exact device identification.

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 25ac6754d144a258d39cd9251677f3e35f4b3ee6
CPU threads: 4; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_HU.UTF-8); UI: en-US
Calc: threaded

(In reply to steve from comment #24)
> On MacBookPro14,3 (15", retina) system preferences > display set to scaled
The GPU in this is a Radeon Pro 555 or 560.

Issue is reproducible on mac Pro 7,1 (2019), Radeon Pro 580X with macOS 11.6.1 (Big Sur).

Radeon Pro 560 4 GB in this 2017 MacBook Pro here

Can not reproduce on iMac, 27-inch, 2020 with a Radeon GPU.

@Tor thanks for taking a look at this and trying to reproduce. Are you running main from https://dev-builds.libreoffice.org/daily/master/current.html or a custom compile? Maybe that makes a difference?

For me this is not hit or miss but 100% reproducible by setting:

    Skia for all rendering (YES)
        Force skia software rendering (NO)

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 1d21a51d814b39711cb1cc7f925b0c620b42eaa7
CPU threads: 8; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded

No repro for me with

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 1d21a51d814b39711cb1cc7f925b0c620b42eaa7
CPU threads: 8; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

MacBook Pro (13 inch, M1, 2020)

@Steve I am running a self-built master.

Oh, and I am running macOS 12.0.1.

No repro for me with

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 1d21a51d814b39711cb1cc7f925b0c620b42eaa7
CPU threads: 8; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

Mac mini (M1, 2020)

Both my tested macOS versions are Monterey, 12.0.1 and not 10.16 as reported by the LO verison info panel.

@Steve : are you by chance using a dark theme ?

Can't reproduce in a self-built LibreOffice master on an M1 MacBook Pro running macOS 12.1 either.

@Alex: yes re: using dark mode. issue persisting with light mode.
back to medium | normal as apparently not all macOS users are affected by this problem.

I still cannot reproduce, and a number of other people apparently can't either, so for those who can reproduce this, questions from comment #10 again, in more detail:

- Can you reproduce this with Skia/Metal enabled (shown in About dialog)? Create a new document, save it and then check the preview of it.
- Can you reproduce this with Skia/Raster enabled (again shown in About dialog)? This can be forced using 'Force Skia software rendering' in the options dialog. Again, create and save a new document.
- If you the problem exists only in one of these two modes, what will happen if you create and save a new document in one mode, then change the mode and start LO again? For both combinations of the two modes.
- Please post the system info from the About dialog.

How are you trying to reproduce and with which exact mac?

Tor tried reproducing, but used a self-compiled build on an M1 mac. So either self-compiling could be a factor or this bug here may be intel mac only. Sadly I do not have an M1 mac to clarify.

Also I do not understand how we are asking about Skia/Raster Skia/Metal. Either rename preferences to follow that naming or use the naming used in preferences. Referencing non-existing preferences is hard to follow up with. There even was a bug about this which got closed as wontfix about changing the naming (can't find it right now).

Reproduced with today's main build on intel mac:

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 8b82a71013567e148166b514d0ce0f5905f5a3e3
CPU threads: 8; OS: Mac OS X 12.4; UI render: default; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded
(yes, about info is pre switching skia on, since skia breaks UI in main build and LO becomes unusable)

I am still not sure how this bug is not critical since Skia is (was?) designated to be the default in the future.

(In reply to steve from comment #39)
> How are you trying to reproduce and with which exact mac?

I start LO, create new Writer document, write 'test', save it, restart LO, and look at the thumbnail.

Mac M1 Mini. But I tested with an Intel Mac before setting this to NEEDINFO.

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 5b21b65572610df88986e700b81f1156aff14f65
CPU threads: 8; OS: Mac OS X 12.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

> (yes, about info is pre switching skia on, since skia breaks UI in main
> build and LO becomes unusable)

I'm not aware of any such problem (and can't reproduce either). Since you mentioned in bug#146842 that your mouse cursor is broken, maybe it's actually a problem with your system?

> I am still not sure how this bug is not critical since Skia is (was?)
> designated to be the default in the future.

It's not critical because:
- a number of people cannot reproduce it
- the info from those who can reproduce it is confusing and incomplete (no answers to comment#10 and comments#38)
- Skia can be disabled for 7.4 again if not deemed in good enough shape (although, the way things are going, the most likely outcome is that it'll stay disabled permantly and then Skia on Mac can rot forever if there's nothing better that could be done with it).

Setting NEEDINFO again (see comment #38).

Created attachment 180983 [details]
Screenshot 2022-06-27  graphic options used

Created attachment 180984 [details]
Screenshot 2022-06-27  main build,  -Skia for all rendering (enabled) -Force Skia software rendering (disabled)

Provided status quo for main build with skia enabled.

There are more skia problems when using an external monitor. But those need to be filed as separate issues.

System and mouse are otherwise fine and also thsoe issues are not happening when not using skia.

(In reply to Luboš Luňák from comment #40)
> - Skia can be disabled for 7.4 again if not deemed in good enough shape
> (although, the way things are going, the most likely outcome is that it'll
> stay disabled permantly and then Skia on Mac can rot forever if there's
> nothing better that could be done with it).

Note, my personal opinion: Skia should be enabled by default on Mac. I'm not getting why it should be disabled for 7.4 again. The major random crashing bug with Raster has been solved.

There obviously bugs, but well that's always the case in the beginning. The user group is pretty small if not being set default. Using the the Skia platform has quite some advantages (especially speed)

Yes, this bug needs attention never the less, but it's surely not a general Intel Mac issue. I have 2 Intel MacBook's at my disposal, but I can't reproduce the issue described here.. 

It's a specific Intel chipset and/or specific driver or firmware causing this, I guess :-( 

And well there is a easy work around, disable Skia manually. So this bug should be a blocker for setting Skia Default, IMHO

I can reproduce this issue (it is actually been like this since I first built on macOS a few months ago, to the point I assumed it is some debug build thing).

There are lost of comments here, so I’m not sure what I can help with debugging this.

(In reply to خالد حسني from comment #46)
> I can reproduce this issue (it is actually been like this since I first
> built on macOS a few months ago, to the point I assumed it is some debug
> build thing).

Nice

> There are lost of comments here, so I’m not sure what I can help with
> debugging this.

The issue is bit specific sub-set of Mac; until now only non-dev users could reproduce it. The Skia expert - Luboš Luňák - couldn't, which made debugging really hard. 

Easiest route maybe pinging Luboš at the libreoffice-dev IRC channel for some guidance. He might lost interest on the Mac part, though.. There where some blockers preventing Skia to be default on Mac (like this bug)

(In reply to خالد حسني from comment #46)
> I can reproduce this issue (it is actually been like this since I first
> built on macOS a few months ago, to the point I assumed it is some debug
> build thing).
> 
> There are lost of comments here, so I’m not sure what I can help with
> debugging this.

@خالد حسني

I cannot reproduce this bug on either my Intel or Silicon machines but I have a theory: somewhere in the vcl code, Skia images are copied with the wrong colorspace. Can you try building LibreOffice with the following patch?:

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

Do you still see the color shifting after rebuilding with the above patch?

From what I could see, Skia stores pixels in 32 bit RGBA format whereas LibreOffice uses 24 bit RGB pixels or 32 bit ARGB pixels. From the screen snapshots attached to this bug, it appears that somewhere RGBA pixels in Skia bitmaps are getting incorrecting converted to RGB or ARGB pixels. This might explain why white pixels (#ffffff) turn yellow (#ffff00).

The patch removes the one colorspace change that I found by grokking for any CGColorSpace and SkColorSpace functions and variables.

(In reply to Patrick Luby from comment #48)
> (In reply to خالد حسني from comment #46)
> > I can reproduce this issue (it is actually been like this since I first
> > built on macOS a few months ago, to the point I assumed it is some debug
> > build thing).
> > 
> > There are lost of comments here, so I’m not sure what I can help with
> > debugging this.
> 
> @خالد حسني
> 
> I cannot reproduce this bug on either my Intel or Silicon machines but I
> have a theory: somewhere in the vcl code, Skia images are copied with the
> wrong colorspace. Can you try building LibreOffice with the following patch?:
> 
> https://gerrit.libreoffice.org/c/core/+/144052
> 
> Do you still see the color shifting after rebuilding with the above patch?

It makes no difference for me. Skia/Metal shows the bad colors, but Skia/Raster don’t.

(In reply to خالد حسني from comment #49)
> It makes no difference for me. Skia/Metal shows the bad colors, but
> Skia/Raster don’t.

Thank you for testing my patch.

Since the problem only occurs with Skia/Metal, I will walk through the macOS Skia code and see if I can find anything different or unique in the Skia/Metal code versus the Skia/Raster code.

I will post another patch if I find any possible fixes.

I have another possible fix. Would anyone be able to try building LibreOffice with the following patch?:

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

Does the above patch change anything? Even if it does not fix this bug, is the color shift different in any way? Any details are much appreciated.

This patch enables 32 bit Skia bitmaps. Internally, LibreOffice uses 24 bit bitmaps (I think it is an old Windows limitation) but on macOS, 32 bit bitmaps are well supported. Switching to 32 bit Skia bitmaps may cause other problems (Luboš Luňák has left many comments about why 24 bit Skia bitmaps are used instead of 32 bits), but at least this patch will tell us if 24-to-32 bit or 32-to-24 bit conversions are the cause of this bug.

(In reply to Patrick Luby from comment #51)
> I have another possible fix. Would anyone be able to try building
> LibreOffice with the following patch?:
> 
> https://gerrit.libreoffice.org/c/core/+/144387
> 
> Does the above patch change anything? Even if it does not fix this bug, is
> the color shift different in any way? Any details are much appreciated.
> 
> This patch enables 32 bit Skia bitmaps. Internally, LibreOffice uses 24 bit
> bitmaps (I think it is an old Windows limitation) but on macOS, 32 bit
> bitmaps are well supported. Switching to 32 bit Skia bitmaps may cause other
> problems (Luboš Luňák has left many comments about why 24 bit Skia bitmaps
> are used instead of 32 bits), but at least this patch will tell us if
> 24-to-32 bit or 32-to-24 bit conversions are the cause of this bug.

It makes no difference for me.

I think that I have narrowed down this bug to drawing 24 bit bitmaps that have an 8 bit alpha bitmap in SkiaSalGraphicsImpl::drawAlphaBitmap(). By default, that method calls SkiaSalGraphicsImpl::mergeCacheBitmaps() which combines the 24 bitand the alpha bitmaps into a single bitmap. My current theory is that SkiaSalGraphicsImpl::mergeCacheBitmaps() is doing something unexpected on some machines.

I have posted the following patch that prints out some debugging data that I am hoping will narrow down the what is causing this bug:

https://gerrit.libreoffice.org/c/core/+/144814/2

If anyone who is experiencing this bug and has a LibreOffice build is willing test out the above patch, can you apply the patch, make, and then do the following steps and post all of the "warn:vcl.skia.debug" messages that appear in the Terminal?:

export SAL_DISABLE_SKIA_BITMAP_MERGE=1
./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep vcl.skia.debug

When LibreOffice launches, open the About dialog, then quit. In addition to the Terminal messages, can you tell me if the large images in the About dialog are still colorshifted like in attachment 176623 [details]?

(In reply to Patrick Luby from comment #53)
> I think that I have narrowed down this bug to drawing 24 bit bitmaps that
> have an 8 bit alpha bitmap in SkiaSalGraphicsImpl::drawAlphaBitmap(). By
> default, that method calls SkiaSalGraphicsImpl::mergeCacheBitmaps() which
> combines the 24 bitand the alpha bitmaps into a single bitmap. My current
> theory is that SkiaSalGraphicsImpl::mergeCacheBitmaps() is doing something
> unexpected on some machines.
> 
> I have posted the following patch that prints out some debugging data that I
> am hoping will narrow down the what is causing this bug:
> 
> https://gerrit.libreoffice.org/c/core/+/144814/2
> 
> If anyone who is experiencing this bug and has a LibreOffice build is
> willing test out the above patch, can you apply the patch, make, and then do
> the following steps and post all of the "warn:vcl.skia.debug" messages that
> appear in the Terminal?:
> 
> export SAL_DISABLE_SKIA_BITMAP_MERGE=1
> ./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep
> vcl.skia.debug
> 
> When LibreOffice launches, open the About dialog, then quit. In addition to
> the Terminal messages, can you tell me if the large images in the About
> dialog are still colorshifted like in attachment 176623 [details]?

No difference or messages reported for me. I also don’t think the issue is limited to images, even the thumbnails in the start center have their white color turned into yellow.

(In reply to خالد حسني from comment #54)
> 
> No difference or messages reported for me. I also don’t think the issue is
> limited to images, even the thumbnails in the start center have their white
> color turned into yellow.

You have a good point about the document thumbnails in the Start Center so I traced how they are drawn. After some experimentation, I think that the document thumbnails as well as the Impress template icons are both rendered using following steps:

1. An offscreen image is created
2. The offscreen image is cleared in white (this is what turns yellow)
3. The thumbnail image is drawn with an alpha mask on top of the offscreen image
4. The offscreen image is drawn to the window

What is interesting to me is that I if I try to skip step 2 by disabling drawing filled rectangles in SkiaSalGraphicsImpl::privateDrawAlphaRect() and drawing filled polygons in SkiaSalGraphicsImpl::performDrawPolyPolygon(), the offscreen image is still filled with white.

So, my current theory is that erasing the background of an offscreen image is where the problem might be. My logic is that LibreOffice colors set alpha values to 1 - Skia's alpha value. What this means is that LibreOffice white color in  ARGB format is #00ffffff. Copy this bit for bit directly to a Skia white color in BGRA format results in yellow.

I post more when I find the code that clears offscreen images.

(In reply to Patrick Luby from comment #55)
> So, my current theory is that erasing the background of an offscreen image
> is where the problem might be. My logic is that LibreOffice colors set alpha
> values to 1 - Skia's alpha value. What this means is that LibreOffice white
> color in  ARGB format is #00ffffff. Copy this bit for bit directly to a Skia
> white color in BGRA format results in yellow.

I found that, in the Start Center's document thumbnails, the thumbnails are bitmap images created from the .png images created when you last saved the document. Also, I found that there is no clearing before drawing the thumbnail bitmap. Instead, the thumbnail image contains all of the white (yellow with the bug) pixels that are drawn. So, I think that the color shift is limited to bitmap images.

Since this bug only affects Skia/Metal and not Skia/Raster, I think that the next area to look at is if the GPU is returning bitmaps with an unexpected pixel format. I have posted the following patch that prints messages with pixel format data for bitmaps fetched from the GPU:

https://gerrit.libreoffice.org/c/core/+/144814/3

If anyone who is experiencing this bug and has a LibreOffice build is willing to run the above patch, can you apply the patch, make, and then do the following steps and post all of the "vcl.skia.peekpixels" messages that appear in the Terminal?:

./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep vcl.skia.peekpixels

(In reply to Patrick Luby from comment #56)
> (In reply to Patrick Luby from comment #55)
> > So, my current theory is that erasing the background of an offscreen image
> > is where the problem might be. My logic is that LibreOffice colors set alpha
> > values to 1 - Skia's alpha value. What this means is that LibreOffice white
> > color in  ARGB format is #00ffffff. Copy this bit for bit directly to a Skia
> > white color in BGRA format results in yellow.
> 
> I found that, in the Start Center's document thumbnails, the thumbnails are
> bitmap images created from the .png images created when you last saved the
> document. Also, I found that there is no clearing before drawing the
> thumbnail bitmap. Instead, the thumbnail image contains all of the white
> (yellow with the bug) pixels that are drawn. So, I think that the color
> shift is limited to bitmap images.
> 
> Since this bug only affects Skia/Metal and not Skia/Raster, I think that the
> next area to look at is if the GPU is returning bitmaps with an unexpected
> pixel format. I have posted the following patch that prints messages with
> pixel format data for bitmaps fetched from the GPU:
> 
> https://gerrit.libreoffice.org/c/core/+/144814/3
> 
> If anyone who is experiencing this bug and has a LibreOffice build is
> willing to run the above patch, can you apply the patch, make, and then do
> the following steps and post all of the "vcl.skia.peekpixels" messages that
> appear in the Terminal?:
> 
> ./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep
> vcl.skia.peekpixels


I also opened About LibreOffice while at it.

With Skia/Metal: https://paste.debian.net/1265585/
With Skia/Raster: https://paste.debian.net/1265583/

(In reply to خالد حسني from comment #57)
> With Skia/Metal: https://paste.debian.net/1265585/
> With Skia/Raster: https://paste.debian.net/1265583/

Thank you for running the patch. The bad news, your output is the same as mine: both machines are using the same pixel format and alpha types.

Looking at the Skia source is a bit overwhelming so I am going to see if I can implement a test when loading Skia/Metal. @Luboš Luñák already does a test at launch so if can detect something unique on machines that have this bug, I can then force LibreOffice to switch to Skia/Raster.

The following patch prints out some debug messages that will tell me if your machine has drawn red, green, blue, or alpha in an unexpected byte within the pixel:

https://gerrit.libreoffice.org/c/core/+/144814/5

Can you apply the patch and post the Terminal messages? There should only be 8 messages:

./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep vcl.skia.colortest

(In reply to Patrick Luby from comment #58)
> (In reply to خالد حسني from comment #57)
> > With Skia/Metal: https://paste.debian.net/1265585/
> > With Skia/Raster: https://paste.debian.net/1265583/
> 
> Thank you for running the patch. The bad news, your output is the same as
> mine: both machines are using the same pixel format and alpha types.
> 
> Looking at the Skia source is a bit overwhelming so I am going to see if I
> can implement a test when loading Skia/Metal. @Luboš Luñák already does a
> test at launch so if can detect something unique on machines that have this
> bug, I can then force LibreOffice to switch to Skia/Raster.
> 
> The following patch prints out some debug messages that will tell me if your
> machine has drawn red, green, blue, or alpha in an unexpected byte within
> the pixel:
> 
> https://gerrit.libreoffice.org/c/core/+/144814/5
> 
> Can you apply the patch and post the Terminal messages? There should only be
> 8 messages:
> 
> ./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep
> vcl.skia.colortest

warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:251: 24 bit red pixel: ffff0000 colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:259: 24 bit green pixel: ff00ff00 colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:267: 24 bit blue pixel: ff0000ff colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:275: 24 bit white pixel: ffffffff colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:298: 32 bit red pixel: aaaa0000 colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:306: 32 bit green pixel: aa00aa00 colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:314: 32 bit blue pixel: aa0000aa colorType: 6
warn:vcl.skia.colortest:95652:3366207:vcl/skia/SkiaHelper.cxx:322: 32 bit white pixel: aaaaaaaa colorType: 6

Which seem identical to your output.

(In reply to خالد حسني from comment #59)
> Which seem identical to your output.

Thank you for testing my patch. You are correct, your output is the same as mine so I think that Skia isn't converting pixels. So, I think the next place for me to investigate is the code where Skia copies its bitmap pixels to the screen.

From what I can see, Skia creates a macOS CAMetalLayer to each LibreOffice NSView and draws to the CAMetalLayer. macOS then copies the CAMetalLayer to the screen in -[NSWindow displayIfNeeded] so maybe the CAMetalLayer has an unexpected pixel format or colorspace Skia does not know how to convert to. 

I will post another debug patch in the next day or so.

(In reply to Patrick Luby from comment #60)
> I will post another debug patch in the next day or so.

The following patch prints out some debug messages containing various attributes of your machine's Metal devices (GPUs), the current CAMetalLayer, and the current NSWindow:

https://gerrit.libreoffice.org/c/core/+/144814/6

Can you apply the patch and post the Terminal messages? There should only be 3 messages:

./instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep vcl.skia.metal

Created attachment 184668 [details]
MacBook Pro Silicon GPU that bug does *not* have this bug

Created attachment 184669 [details]
MacBook Pro Intel GPU that bug does *not* have this bug

My current theory is still that this bug is caused by certain GPUs are not able to handle the combining of 24-bit opaque and 8-bit alpha bitmaps.

Apple provides some ways to test the feature set of a particular GPU, so I am curious if those of you who experience this bug have a particular set of GPU features or limitations that is different from other machines.

Can anyone who experiences this bug upload a screenshot using the following?:

1. Select the Apple > About This Mac menu item
2. In the window that appears, click the System Report button
3. In the window that appears, select Graphics/Displays in the sidebar
4. Take a screen snapshot of the window by pressing Command-Shift-5 and clicking on the window.
5. Upload the screen snapshot from your Desktop as an attachment

I don't see this bug on either of my Intel or Silicon MacBook Pros but I have uploaded screen snapshots for comparison in attachment 184668 [details] and attachment 184669 [details].

(In reply to Patrick Luby from comment #61)
> The following patch prints out some debug messages containing various
> attributes of your machine's Metal devices (GPUs), the current CAMetalLayer,
> and the current NSWindow:
> 
> https://gerrit.libreoffice.org/c/core/+/144814/6
> 

I posted a new patch that will compile on a macOS Intel machine:

https://gerrit.libreoffice.org/c/core/+/144814/7

I had not realized the various MTLDevice and CAMetalLayer calls I used did not get added until macOS Big Sur and LibreOffice on macOS Intel machines compiles to run on macOS Catalina so I had to tweak the patch a bit.

Created attachment 184971 [details]
2023-01-28 intel mac, does *have* this bug, Intel HD Graphics 630

Created attachment 184972 [details]
2023-01-28 intel mac, does *have* this bug, Radeon Pro 560

MacBookPro14,3
2023-01-28 intel mac, does *have* this bug, Intel HD Graphics 630
2023-01-28 intel mac, does *have* this bug, Radeon Pro 560
screenshots as requested in https://bugs.documentfoundation.org/show_bug.cgi?id=145988#c64

Patrick: I tested today's main build, including your patch from https://bugs.documentfoundation.org/show_bug.cgi?id=147342#c19 and sadly the color issues for images are persisting with macOS 13.2 and the following main build. The yellow document previews in Start Center + Impress Template selection are persisting as is the yellow image in About Window. The issue looks identical to the screenshots I posted back in 2021 except I am now using dark mode, which does not change anything in regards to the issue.

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

(In reply to steve from comment #67)
> Created attachment 184972 [details]
> 2023-01-28 intel mac, does *have* this bug, Radeon Pro 560
> 
> MacBookPro14,3
> 2023-01-28 intel mac, does *have* this bug, Intel HD Graphics 630
> 2023-01-28 intel mac, does *have* this bug, Radeon Pro 560
> screenshots as requested in
> https://bugs.documentfoundation.org/show_bug.cgi?id=145988#c64
> 

Thank you for the screen snapshots. What jumped out at me is that the following line for the Radeon Pro 560 GPU:

Framebuffer Depth: 30-Bit Colour (ARGB2101010)

On both my machines, both the built-in monitor and my external non-retina monitor connected via HDMI are 32-bit color (ARGB888) and Skia, internally uses the same pixel format. So, my current theory is mismatched pixel format between what Skia wants to use and what the Radeon Pro 560 wants to use.

I will do some experimentation over the next few days and see if I can see any Skia code that is ignoring pixel format differences. I'll post again when I have some news.

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

https://git.libreoffice.org/core/commit/620ad1b7ae06d6f053fb2c9b57af96b736c04e57

Related: tdf#145988 Reset layer's pixel format to MTLPixelFormatBGRA8Unorm

It will be available in 7.6.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.

(In reply to Patrick Luby from comment #68)
> I will do some experimentation over the next few days and see if I can see
> any Skia code that is ignoring pixel format differences. I'll post again
> when I have some news.

I have added a potential fix starting in the 2023-01-29 nightly build. While experimenting, I found that when a window moves to another screen, macOS may change the pixel format of the window's CAMetalLayer. Skia forces the pixelFormat to RGBA8888 when it creates the CAMetalLayer, so I added code to force it to RGBA8888 when the screen has changed as well.

Would anyone be willing to try the latest nightly build and see if there is any change in the thumbnail image colors or the Help > About dialog image colors? If there is no change in colors, can you run the nightly build from the Terminal using the following command and then paste any output in the Terminal that you see? I'm looking for any output lines with "vcl.skia.metal" in them:

/Applications/LibreOfficeDev.app/Contents/MacOS/soffice

This is indeed depending on the specific combination of graphics chip. Testing on an iMac13,2 with skia enabled does not expose this issue.

The issue on MacBookPro14,3 however persists with main build from 2023-01-30:
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ec4babad021218b75dfe8534985d7db525edde69
CPU threads: 8; OS: Mac OS X 13.2; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

The issue happens with or without external monitor. So switching screens should not play into the equation.

Running from terminal with `/Applications/LibreOfficeDev.app/Contents/MacOS/soffice` outputs the follwoing:

warn:i18nlangtag:9987:420005:i18nlangtag/source/isolang/isolang.cxx:1442: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:i18nlangtag:9987:420005:i18nlangtag/source/isolang/isolang.cxx:1442: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:i18nlangtag:9987:420005:i18nlangtag/source/isolang/isolang.cxx:1442: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016
warn:i18nlangtag:9987:420005:i18nlangtag/source/isolang/isolang.cxx:1442: convertIsoNamesToLanguage(string_view): on-the-fly for {en-DE} 2016

Sadly nothing with `vcl.skia.metal`.

This is `Use Skia for all rendering` (enabled) `Force Skia software rendering` (disabled).

Not sure if related but this crash showed up while testing. Crash is reproducible when opening settings:

https://bin.disroot.org/?9209695689b5eb84#HBhS2rKDPhTN9Sj6TeYe6TwbfvZEqkA9v9dSkfEhDonR

(In reply to steve from comment #71)
> 
> The issue happens with or without external monitor. So switching screens
> should not play into the equation.
> 
> Not sure if related but this crash showed up while testing. Crash is
> reproducible when opening settings:
> 
> https://bin.disroot.org/
> ?9209695689b5eb84#HBhS2rKDPhTN9Sj6TeYe6TwbfvZEqkA9v9dSkfEhDonR

Thank you for testing my latest patch. It is interesting that the issue happens without an external monitor on your MacBook Pro. So, just to make sure that I understand correctly, if you disconnect the external monitor and restart LibreOffice, the issue still occurs, right?

As for the crash, I may be proven wrong, but I think that is an unrelated bug. The crash is occurring when LibreOffice tries to generate a cryptographic key presumably for use when encrypting or decrypting documents.

Anyway, since forcefully setting the window's CAMetalLayer pixel format to match Skia's pixel format doesn't fix the issue, maybe the next thing I can try is to do the opposite and never set the CAMetalLayer's pixel format at all. My theory here is that CAMetalLayer is failing to convert BGRA8888 pixels to the screen's  ARGB2101010 pixel format. Maybe by pushing the pixel conversion up into the Skia code is a possible solution.

I will need to do some more experimenting and I will post again when I have some news.

(In reply to Patrick Luby from comment #72)
> I will need to do some more experimenting and I will post again when I have
> some news.

Maybe it's worth considering remote-debugging? Could be a lot faster.

(In reply to Telesto from comment #73)
> Maybe it's worth considering remote-debugging? Could be a lot faster.

Interesting idea. Do you have any ideas how that would work? I think so far the big limitation is that we've only found one person that experiences this bug *and* has a local LibreOffice build.

I do think we are much closer to finding the cause of this issue. What I do know now is that this bug occurs only with images loaded by LibreOffice into a bitmap. The colors of shapes and text are OK so Skia is passing down non-bitmap drawing instructions accurately even for those who experience the bug.

The key is that this bug occurs when you have a monitor that expects ARGB2101010 pixels (i.e. monitors with a 30 bit depth). From what I have seen, this issue only occurs when LibreOffice loads in image (e.g. icons, PNG files, JPEG files, etc.) into a bitmap buffer, LibreOffice writes pixels in the BGRA8888 pixel format to the bitmap buffer and then hands the bitmap buffer to Skia. Skia eventually draws the bitmap buffer to Metal's CAMetalLayer with the assumption that Metal's CAMetalLayer will convert the pixel format to the format the screen expects. This last step is where I think the issue occurs.

What I still don't know is if this issue affects all GPUs that support 30 bit depth monitors. In other words, does the issue occur in all 30 bit depth monitors or only the Radeon 560 GPU?

One question for @Telesto: this issue does *not* occur on your machine, right? If yes, do you have a monitor with a 30 bit depth like @steve? Also, can you post screen snapshots of your GPU/display configuration using the steps in comment 64? I can then compare your configuration to @steve's snapshot snapshots.

(In reply to Patrick Luby from comment #74)
> (In reply to Telesto from comment #73)
> > Maybe it's worth considering remote-debugging? Could be a lot faster.
> 
> Interesting idea. Do you have any ideas how that would work? I think so far
> the big limitation is that we've only found one person that experiences this
> bug *and* has a local LibreOffice build.

Arranging something like this a bit complicated part. Starting with a volunteer, and practical time slot (amount of time available & time-zone differences etc)

Khaled & Steve are both experiencing the issue. Khaled has development environment setup. 

> One question for @Telesto: this issue does *not* occur on your machine,
> right? 

Yes, I have access to two Intel MacBook without the issue, both iGPU

>If yes, do you have a monitor with a 30 bit depth like @steve? 

No

> Also, can you post screen snapshots of your GPU/display configuration using the
> steps in comment 64? I can then compare your configuration to @steve's
> snapshot snapshots.
Sure. I will post those later today

(In reply to Telesto from comment #75)
> Khaled & Steve are both experiencing the issue. Khaled has development
> environment setup. 
> 

It would be interesting to see if the GPU/display configuration for Khaled's machine is the same or similar to @steve's machine.

@خالد حسني Would it be possible to attach screen snapshots of your GPU/display configuration using the steps in comment 64?

> Sure. I will post those later today

Thank you. Even though you and I have only 24 bit depth, it will be good to have screen snapshots to build a list of GPUs that work and those that don't.

If the list of GPUs that don't work is small enough, implementing a "at laucnh, check the GPU name and bit depth, if 30 bit depth and the GPU is on a short list of GPUs that don't work, immediately switch to Skia/Raster".

> if you disconnect the external monitor and restart LibreOffice, the issue still occurs, right?

Travelling today so there was never an external monitor involved in reproducing today to begin with.

@Patrick You are welcome to reach out via email and we can do a remote debugging session, if you think it will be useful to you. I don't self-compile LO though.

Created attachment 185017 [details]
Screenshot Intel Iris Plus 645 that does *not* have this bug

I saw that LibreOffice uses a much newer version of Skia. Has anyone who has experienced this bug tried the latest nightly master build? If yes, do you see any change good or bad?

Thanks for pinging about this, Patrick. Retested and I am no longer able to reproduce the problem, so your theory about an updated Skia resolving this problem sounds reasonable. Glad this issue is a thing of the past 🚀

Resolved - Worksforme, as we don't have a specific commit fixing this.

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

(In reply to steve from comment #80)
> Thanks for pinging about this, Patrick. Retested and I am no longer able to
> reproduce the problem, so your theory about an updated Skia resolving this
> problem sounds reasonable. Glad this issue is a thing of the past 🚀

That is very good news.

@خالد حسني IIRC you were the only other commenter who could reproduce this build. Are you still seeing it with the master or libreoffice-7-6 builds?

I confirm this is working for me now as well. I usually force Skia/Raster so I missed when this got fixed.

(In reply to ⁨خالد حسني⁩ from comment #82)
> I confirm this is working for me now as well. I usually force Skia/Raster so
> I missed when this got fixed.

Excellent! Marking as verified/fixed by the upgrade of Skia from version m103 to m111:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9c9a711ac5d8f32ac318d0e4ecab7b3a26bc2150

(In reply to Patrick Luby from comment #83)
> Excellent! Marking as verified/fixed by the upgrade of Skia from version
> m103 to m111:
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=9c9a711ac5d8f32ac318d0e4ecab7b3a26bc2150

https://bugs.documentfoundation.org/show_bug.cgi?id=156881 indicates that this bug still occurs in LibreOffice 7.6 builds. Since LibreOffice 7.6 branches use Skia version m111, I now believe that the upgrade from Skia version m111 to m116 is what fixed this bug:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=f8c15850dbfaa46605e1e353ae1f49e69184e8a1