In the iOS app, open a spreadsheet, and switch to edit mode. => Note the black background of formula bar icons, and the large triangle. Opening the sidebar reveals several more similar icons. The large triangle might be fixed by tdf#134054. This occurs with app test version 4.2.6 (60) (that's based on online master + cp-6.4).
Created attachment 163074 [details] Screenshot https://gerrit.libreoffice.org/c/core/+/98851 helps a bit (gets rid of the black background), but even then the icons look quite weird, a washed out light blue. (Look at the upper half of the sidebar.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/837879ec7b1f3cdfee2b7af4ec44885db0d115e6 tdf#134832: Don't set mbSupportsBitmap32 on iOS It will be available in 7.1.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.
After about a week of investigation and experimentation here and there, with days spent in the Xcode debugger, no solution yet. But at least I know that there are multiple problems that together cause the effect;) Changing one thing in one place might fix one aspect but others remain. One part of the code that I am particularly skeptic about is the QuartzSalBitmap::CreateWithMask() in vcl/quartz/salbmp.cxx. I have a re-implementation of that which is simpler (more straightforward direct manipulation of the bitmap buffers) and gets rid of the black background, producing baked-in alpha in a normal CGImage instead of a masked image as produced by CGImageCreateWithMask() (which quite possibly does not work as we expect, in all the contexts where we attempt to use it). But why do the icons still after that end up as light yellow? Presumably that is because at some place in the code, a bitmap that we have set up as BGRA format (in memory order) is interpreted instead as being ARGB, meaning that grey pixels of the "B" for instance (BGRA: 0x69, 0x69, 0x69, 0xFF, i.e. RGB: #696969 with alpha: 0xFF) get interpreted as parti transparent yellow (RGB: #696900 with alpha: 0x69).
Er, some obvious thinko in my ARGB thing above, ignore it.
What I meant is that if we have a bitmap that is BGRX (i.e. BGR and an ignored fourth byte, what CoreGraphics calls kCGImageAlphaPremultipliedFirst | kCGImageByteOrder32Little), and the ignored fourth byte is zero, and some code (that I haven't found) interprets that as ARGB, then grey turns into semi-transparent yellow. If the mysterious code on the other hand interprets it as ABGR, then grey turns into semi-transparent light cyan. I have seen both instead of the grey that is expected, when I have experimented with changing something in the code...
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9d1db290b6c81afc6fad7ce49523be5d8e7c6dc5 tdf#134832: Also run the BitmapTest from vcl It will be available in 7.1.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.
The current state is that the icon background is not black any longer (it is transparent, as it should be), but the icons themselves are light yellow (possibly partially transparent yellow), not grey. It is infuriating. I am sure that the fix will be a very small change somewhere. But I haven't been able to find it. Clearly the bug is caused by some mismatch between what format some bitmap (or CGContext or CGImage created from a bitmap) actually is, and how it is interpreted at some place. There are a handful of places in vcl where I have tried changing N32BitTcAbgr to N32BitTcBgra, or kCGImageAlphaNoneSkipFirst to kCGImageAlphaPremultipliedFirst, with kCGImageByteOrder32Little or not, or similar changes. But I have not managed to come up with the right magic combination that would fix the problem.
There are two hard problems in computer science: cache invalidation and naming things. In this case, my investigation of this bug was seriously hampered by the first problem. In other words, I had no idea that the core code keeps a cache of scaled icons. Once an incorrectly rendered icon had ended up in that cache, it was re-used over and over again. No changes I made to the code that would produce the icon actually had any visible effect. But when I uninstall the app first (which removes all its files, including that icon cache), it looks fine. Re-building core now from a fresh pull to double-check. Stay tuned.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/online/commit/377e9266c9cd18de3e39032f79f9d2d544b72e7b tdf#134832: Clear the cache directory if it is for another version of the app
This was fixed, let's close. Thanks, Tor!