Description: Upon inserting a new table in a document, the screen renders weird lines while adjusting its cells' height or width Steps to Reproduce: 1.Open Libreoffice, choose Create Writer document 2.Insert a table 3.Drag the table borders to adjust the cells height/width Actual Results: The table is adjusted correctly but the screen displays the "temporary" lines drawn while the borders were being adjusted Expected Results: The table is adjusted correctly and the screen is clear after releasing the mouse button Reproducible: Always User Profile Reset: No Additional Info: Video here: https://twitter.com/gcesarmza/status/1706697286611345682
This has to be a M1/ARM bug. I cannot reproduce this on intel macs. (M1 is just in use, cannot check it at the moment
confirmed using Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 10; OS: Mac OS X 13.6; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Apple M1 Pro 14", 2021 with external screen (26,5-Zoll (1920 × 1080))
as mentioned by gcesarmza on twitter: 7.5 was working fine. I didn't double-checked it. bibisectrequest/regression
Something I didn't mention earlier: Installing the X86_64 version in the M1 Mac doesn't help, the bug is still there.
I just downgraded to 7.5.7.1 (AARCH64) and the bug is not happening at all.
(In reply to gcesarmza from comment #5) > I just downgraded to 7.5.7.1 (AARCH64) and the bug is not happening at all. Would you mind to test a master build too. LibreOffice 7.6 uses Skia m111. Master uses Skia version m116. Some bugs are gone with the more recent Skia version. There where some similar bugs which are gone now. https://dev-builds.libreoffice.org/daily/master/current.html ---- Alternative solution: use Skia Raster instead of Skia/Metal. LibreOffice -> Preferences -> View. Check Force Skia Software rendering. Press OK and restart
Checking the option "Force Skia Software rendering" fixes the issue in this build Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Mac OS X 14.0; UI render: Skia/Raster; VCL: osx Locale: en-US (en_AR.UTF-8); UI: en-US Calc: threaded Also, I installed this build (2023-10-03 05:13:24) and it keeps failing. Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 9389102ee5e6adbb0f8b10f8aee60d1899d91d27 CPU threads: 8; OS: macOS 14.0; UI render: Skia/Metal; VCL: osx Locale: en-US (en_AR.UTF-8); UI: en-US Calc: threaded Switching to software rendering solves the issue in this dev build, just like in 7.6.2.1
I downloaded today's nightly master build and I cannot reproduce this on my Silicon MacBook Pro: Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 9389102ee5e6adbb0f8b10f8aee60d1899d91d27 CPU threads: 8; OS: macOS 14.0; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded I wonder if this bug only occurs with a particular GPU. Can you run the nightly build that you installed in the Terminal using the following command?: /Applications/LibreOfficeDev.app/Contents/MacOS/soffice You should see a "Default MTLDevice is" message in the Terminal. Can you paste that message into this bug? The output from my machine is below: warn:vcl.skia:36049:11155849:vcl/quartz/cgutils.mm:105: Default MTLDevice is "Apple M1 Pro"
I just downloaded the daily and for this mac the problem is fixed! MacOSX-aarch64@tb94-TDF 2023-10-04 05:15:21 Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: f95c3994f0b6a82a3bc2ddfb68822b74479ae185 CPU threads: 10; OS: macOS 13.6; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded (In reply to Patrick Luby from comment #8) > I wonder if this bug only occurs with a particular GPU. Can you run the > nightly build that you installed in the Terminal using the following > command?: > > /Applications/LibreOfficeDev.app/Contents/MacOS/soffice > > You should see a "Default MTLDevice is" message in the Terminal. Can you > paste that message into this bug? The output from my machine is below: > > warn:vcl.skia:36049:11155849:vcl/quartz/cgutils.mm:105: Default MTLDevice is > "Apple M1 Pro" warn:vcl.skia:2489:70157:vcl/quartz/cgutils.mm:105: Default MTLDevice is "Apple M1 Pro"
During my tests I removed ~/Library/Application Support/LibreOffice to start with a new profile Reinstalled 7.5.7 and got this: - Disabling and re-enabling Skia without software rendering makes the problem appear. This is new, 7.5.7 used to work well - There is no log for "Default MTLDevice" in 7.5.7 Reinstalled 7.6.2.1 and got this: - Disabling Skia rendering fixes the problem - Enabling Skia with Software rendering fixes the problem - Enabling Skia without software rendering makes the problem appear - There is no log for "Default MTLDevice" in 7.6.2.1 Downloaded and installed MacOSX-aarch64@tb94-TDF 2023-10-04 05:15:21: - xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app - Removed ~/Library/Application Support/LibreOfficeDev to start with a new profile - warn:vcl.skia:9167:385121:vcl/quartz/cgutils.mm:105: Default MTLDevice is "Apple M1 Pro" - Skia enabled without software rendering: works OK! - Disabled Skia: works OK! - Re-enabled Skia: works OK! - Skia enabled with software rendering: works OK! - Disabled software rendering: works OK!
(In reply to gcesarmza from comment #10) > - warn:vcl.skia:9167:385121:vcl/quartz/cgutils.mm:105: Default MTLDevice is > "Apple M1 Pro" It appears that you and I have the same GPU so that is good to hear that the bug no longer occurs in the nightly master build for you. I downloaded LibreOffice 7.6.2.1 and, like you, I can also reproduce the bug with Skia/Metal but not with Skia/Raster or Skia disabled. So, I will see if any of my recent Skia fixes to master have not been backported to LibreOffice 7.6. I will post again when I have some news.
(In reply to Patrick Luby from comment #11) > I downloaded LibreOffice 7.6.2.1 and, like you, I can also reproduce the bug > with Skia/Metal but not with Skia/Raster or Skia disabled. > > So, I will see if any of my recent Skia fixes to master have not been > backported to LibreOffice 7.6. I found the patch that fixed this bug in the nightly master builds: it was the upgrade to Skia version m116. LibreOffice 7.6.2.1 uses the older Skia version m111. I am not sure if it is a good idea to change the Skia version in LibreOffice 7.6 so we might have to wait for LibreOffice 24.2 to be officially released. I will leave this bug open because there is still one case where this bug occurs: if you hide the sidebar and drag a horizontal table border, artifacts will be drawn in the right page margin. And, like the original bug report, these artifacts are only drawn when using Skia/Metal.
Created attachment 191279 [details] Video Showing Rendering Artifacts (Mac OS, 7.6.0.3) Just for future Bugzilla knowledge, I attached the Twitter video showing off the bug.
So this bug can now be closed as resolved, or?
Persisting in Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: afe19beb79c3f88e42fd4b1d9b87cd324092197f CPU threads: 12; OS: macOS 14.6.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded As Patrick mentioned: only seeing the artifacts when changing horizontal table line and they show on the right side. Changing vertical table line does not result in artifacts.
No longer able to reproduce in Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 3a8278c42e14b03eb57987adf33b6d61bfb3f856 CPU threads: 12; OS: macOS 15.0.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Test was done with hidden sidebar. If you were affected by this issue, please also re-test with latest main build from https://dev-builds.libreoffice.org/daily/master/current.html and report back if the issue is also resolved for you.