https://bugs.documentfoundation.org/show_bug.cgi?id=145988
--- Comment #57 from خالد حسني <kha...@aliftype.com> --- (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/ -- You are receiving this mail because: You are the assignee for the bug.
