Description: I am using hardware accelerated Skia on a M2 MacBook Air with LO 7.4.5.1. When I click somewhere in LO Writer, the blinking cursor jumps to that spot as intended. If I then click on another spot, the blinking cursor jumps there too. The problem is, that on the spot, where the cursor was before, there is a small line leftover from the cursor. I can reapeat that constantly and I have a lot of remaining lines in the document. If I start scrolling the document, the leftovers disappear (and come back, if I move the cursor again). It also happens in LO Calc, when I click around in a active cell. It also happens when using the arrow keys to move the cursor. Steps to Reproduce: 1. Open LO Writer and be sure, that Skia is active (but not software accelerated) 2. Write a text 3. Move the cursor (by mouse or with the arrow keys) Actual Results: The cursor moves, but graphical lines remain at the old position. Expected Results: There should be no graphical remains. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.5.1 / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Mac OS X 13.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
Created attachment 185047 [details] Screenshot
Confirm Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d8ae6d1388f28c405c4de2dfe93dbfe2d8acd470 CPU threads: 8; OS: Mac OS X 12.6.3; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded 1. Open attachment 179678 [details] 2. Press and hold arrow left, at the end of the first line of text Only with Skia/Metal (fine with Skia Raster/Software mode)
I just found out, that it also happens when moving the ruler.
Also happens on LO 7.5.0.3
@V Stuart Foote Does this also happen with Skia Vulkan on Windows?
(In reply to Telesto from comment #5) > @V Stuart Foote > Does this also happen with Skia Vulkan on Windows? Looks like it does, seeing bug 155320
*** Bug 155320 has been marked as a duplicate of this bug. ***
Would be great if affected users could test earlier releases and see if this issue is a regression. If you do test, please make sure to paste the About information here.
I do see it on Windows builds as well. STR 1. blank writer doc 2. apply the dt <F3> 3. locate the "He was dripping with sweat now," passage 4. mouse point into dripping 5. cursor (L,R) and I'm seeing the affect Almost seems it is an off by 1 size calculation for the text cursor when it is being moved left or right after the pointer click into canvas. The os/DE defined width of the cursor (narrower or wider) does not affect the "ghost" left. Skia raster frame is not affected, only with Vulkan rendering. Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: e08c910f9ee520ce00fe99d6dab9988138996ee3 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded RenderMethod: vulkan Vendor: 0x8086 Device: 0x8a52 API: 1.2.151 Driver: 0.402.661 DeviceType: integrated DeviceName: Intel(R) Iris(R) Plus Graphics Denylisted: no Will check a couple of older nVidia GPUs, but suspect it will be Vulkan or Metal driver/hardware dependent. Reasonable work around is for users to disable Skia Vulkan/Metal, and possibly set a deny list for affected GPU/os pairings.
(In reply to Stéphane Guillou (stragu) from comment #8) > Would be great if affected users could test earlier releases and see if this > issue is a regression. > If you do test, please make sure to paste the About information here. On macOS the earliest release with Skia support is 7.3. I tested it with Version: 7.3.0.1 / LibreOffice Community Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d CPU threads: 8; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Still the same.
I can reproduce this with the latest libreoffice-7-6 code but, interestingly, I cannot reproduce it with the latest nightly master build. The nightly master builds include a significant number of Skia changes and it appears to me that one or more of those changes have also fixed this bug. Can anyone download the latest main installer from the following link and confirm that this bug is fixed in the latest nightly builds? In the meantime, I will see if I can find any code changes in master that I can backport to libreoffice-7-6: https://dev-builds.libreoffice.org/daily/master/ Important notes: 1. Only download *.dmg files that are dated 27 July 2023 or later 2. The *.dmg files are not codesigned so you will need to execute the following command in the Terminal for each of the *.dmg files that you download: xattr -d com.apple.quarantine </path/to/your/downloaded/file.dmg>
*** Bug 156563 has been marked as a duplicate of this bug. ***
I was able to reproduce this issue, when I move the indentation on the ruler, with a iMac 21.5" Intel running macOS 13.5 with the current release of LibreOffice Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 4; OS: Mac OS X 13.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Downloaded the current nightly build and I was unable to reproduce the problem Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1f2c7422216f568b148ddfbe75412d605335c110 CPU threads: 4; OS: Mac OS X 13.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
So it seems that this bug is fixed in master so I am marking it as resolved/fixed. I assume that the fix is a byproduce of commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 which included several changes for inverting bitmaps and alpha masks.
*** Bug 157251 has been marked as a duplicate of this bug. ***
I'm the author of Bug 157251, which is a duplicate of this one. In my case the issue has been solved thanks to a recommendation from Telesto, without needing to download the latest master build. Following Telesto, I have gone to Tools/Options/LibreOffice/View and I've checked the box "Force Skia Software Rendering", and the bug is now fixed. Alternatively it also works well if I uncheck both "Use Skia For All Rendering" and "Force Skia Software Rendering", but I check "Use Hardware Acceleration". I don't know if these tricks will work for everyone.
@Victor Graus: Changing the render mode is not a bug fix, it's a workaround. Using Skia is actually the reason of the bug. ----- I just downloaded LibreOffice_7.6.2.1_MacOS_aarch64.dmg from September 27. The bug is still there. So why is this bug marked as fixed?
(In reply to lupurus from comment #18) > I just downloaded LibreOffice_7.6.2.1_MacOS_aarch64.dmg from September 27. > The bug is still there. So why is this bug marked as fixed? As I noted in https://bugs.documentfoundation.org/show_bug.cgi?id=153306#c15, I marked this resolved/fixed starting with LibreOffice 24.2. AFAICT, this bug was within the third-party Skia code which was shipped with LibreOffice 7.6. A newer version of Skia is in LibreOffice 24.2 (i.e. the next release) and that appears to fix the Skia bug that causes this bug. I'm just a volunteer here and I am not a Skia expert so I don't know if there are any plans to backport the newer Skia version to LibreOffice 7.6 so feel free to reset the status to whatever you want. It's your bug.
Yes, forcing/disabling Skia is a workaround, but in my case it works, I hope it does for you. Anyway I don't see any difference between using one render mode or another (though I don't know much about computers/libraries). If in the next versions (wait a few months) the bug persists perhaps you could mark it as "Reopened".
(In reply to Patrick Luby from comment #19) > As I noted in > https://bugs.documentfoundation.org/show_bug.cgi?id=153306#c15, I marked > this resolved/fixed starting with LibreOffice 24.2. > > AFAICT, this bug was within the third-party Skia code which was shipped with > LibreOffice 7.6. A newer version of Skia is in LibreOffice 24.2 (i.e. the > next release) and that appears to fix the Skia bug that causes this bug. > > I'm just a volunteer here and I am not a Skia expert so I don't know if > there are any plans to backport the newer Skia version to LibreOffice 7.6 so > feel free to reset the status to whatever you want. It's your bug. Oh, I didn't know that. Unfortunately I cannot find any alpha version of 24.2, so I cannot test it. But I will beleive you :) Thanks for fixing that bug. (In reply to Victor Graus from comment #20) > Yes, forcing/disabling Skia is a workaround, but in my case it works, I hope > it does for you. > > Anyway I don't see any difference between using one render mode or another > (though I don't know much about computers/libraries). Yes, it works, of course, but besides the glitchy UI, I had the feeling, that using Skia at least improves a little bit the smootheness, especially on scrolling.
(In reply to lupurus from comment #21) > Oh, I didn't know that. Unfortunately I cannot find any alpha version of > 24.2, so I cannot test it. Daily builds are here: https://dev-builds.libreoffice.org/daily/master/current.html It would be great if you could also confirm it fixes it for you in 24.2. (And change the status from "resolved" to "verified" if it does.) Regarding the issue not being fixed in 7.6: often, changes are too big to backport in stable branches, as they could bring in new regressions. That's why you might see bugs fixed in trunk but not in existing release branches.
I installed an 24.2 alpha => Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b CPU threads: 8; OS: macOS 14.1.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Interestingly, it works if you move the cursor on the left side of the page. If you move it on the right side, the cursor still shows the old behaviour. So the bug seems not to be fixed for me
7.6.2.1
*** Bug 158435 has been marked as a duplicate of this bug. ***
Created attachment 191733 [details] Cursor trails
The way this issue manifests seems to depend on screen characteristics. I have a MacBook Pro and a 4K external display. Attachment 191733 [details] shows the same document open in three different configurations: – top: v7.6.4.1, external display, zoom 110% – middle: v24.8.0.0.alpha0+, external display, zoom 160% – bottom: v24.8.0.0.alpha0+, built-in display, zoom 100% Not shown: v24.8.0.0.alpha0+, external display, zoom 110%, which doesn’t exhibit the bug. When using the external display, the horizontal point in which the artifacts appear has in the nightly build moved so far to the right that the trails won’t show up until the zoom level is increased. But for some reason, this improvement hasn’t carried over to the internal display. Also, please see attachment 190367 [details] (posted in a duplicate bug) exhibiting partial cursor trails to the left of the horizontal cutoff point. This only happened with certain fonts, but right now I’m unable to reproduce it at all. Anyway, perhaps some of this can provide clues as to what’s going on.
I was not able to replicate this on my setup. I'm using a 1440p monitor on windows with the following version: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_DE); UI: en-US Calc: CL threaded
(In reply to John from comment #28) > I was not able to replicate this on my setup. I'm using a 1440p monitor on > windows with the following version: > > Version: 24.2.0.3 (X86_64) / LibreOffice Community > Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 > CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_DE); UI: en-US > Calc: CL threaded I think this bug is macOS only (what maybe is the reason, why there is still no fix of this issue).
Created attachment 193712 [details] High zoomed document with Skia/Metal
(In reply to bintoro from comment #27) > When using the external display, the horizontal point in which the artifacts > appear has in the nightly build moved so far to the right that the trails > won’t show up until the zoom level is increased. But for some reason, this > improvement hasn’t carried over to the internal display. > > Also, please see attachment 190367 [details] (posted in a duplicate bug) > exhibiting partial cursor trails to the left of the horizontal cutoff point. > This only happened with certain fonts, but right now I’m unable to reproduce > it at all. Anyway, perhaps some of this can provide clues as to what’s going > on. I can now reproduce this bug with the latest LibreOffice code using the document in comment #2 if I set the document zoom to 350% or more. Then, I need to right arrow to the least few letters in a line to see the bug: https://bugs.documentfoundation.org/attachment.cgi?id=193712 Since Skia/Raster is fine, maybe Skia/Metal (and maybe Skia/Vulkan on Windows?) is mishandling upscaling? Not sure how we would debug this though.
Forgot to post my LibreOffice About dialog details: Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 1d5630c5deeec5dca724c29ec8c886bfa71a2099 CPU threads: 8; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Curious. I can also confirm the bug with skia/metal and zoom level 310 %. Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 38ed8100872913c64941927bba665e4bd1a44c12 CPU threads: 12; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
For me it also happens when using zoom 100 %. The best way to reproduce the bug I found out, is, when you type in the text (or a lot of space characters), at least until the middle of the line. Then, when the cursor is at the end of this line, press the left arrow key several times.
(In reply to lupurus from comment #34) > For me it also happens when using zoom 100 %. The best way to reproduce the > bug I found out, is, when you type in the text (or a lot of space > characters), at least until the middle of the line. Then, when the cursor is > at the end of this line, press the left arrow key several times. I can reproduce what you see with LibreOffice 7.6.6. However, the problem is that in the newer LibreOffice 24.2.2, I cannot reproduce what you see. With LibreOffice 24.2.2, the only way I can reproduce the bug is by zooming a Writer document more than 300%.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/05d3a99aa687ee4e1706f9403651379b7ebdad89 tdf#153306 prevent subpixel shifting of X coordinate It will be available in 24.8.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 for this bug. The fix should be in tomorrow's (28 April 2024) nightly master builds. This fix only fixes the LibreOffice 24.2 behavior (i.e. need to zoom to at least 300% to see the bug): https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
I forgot to add that I have also submitted a fix for LibreOffice 7.6.6 (i.e. the version currently in the Mac App Store). Hopefully my fix is not too late for inclusion in the LibreOffice 7.6.7 and Mac App Store releases: https://gerrit.libreoffice.org/c/core/+/166721
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2-3": https://git.libreoffice.org/core/commit/77c26dae7c984f5c60206091f87897079c8a5d93 tdf#153306 prevent subpixel shifting of X coordinate It will be available in 24.2.3. 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.
Reopening and unassigning myself since I only fixed this bug for Skia/Metal on macOS. I assume a similar but likely different fix will need to be implementated for Skia/Vulkan on Windows and Linux but I do not have access to any Windows or Linux machines.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/9fc1e9e0d438a0a36e1e93826312170c9c2dac2a tdf#153306 prevent subpixel shifting of X coordinate It will be available in 7.6.8. 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.
Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 7a895ec4205659038aa95941b65715fed1a3e7be CPU threads: 12; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded confirming the fix or at least I am no longer to reproduce. I think it might be a good idea to set this issue to macOS only, and create a new issue for the remaining trouble on windows and linux. Maybe re-open https://bugs.documentfoundation.org/show_bug.cgi?id=155320 for windows. Clearly the bug needs to be resolved on a per OS basis, so by the one issue per bug rule this should be separate bugs.
OK resolving this against macOS and Metal, residual for Windows issues with Skia Vulkan to previous dupe bug 155320
Thanks Stuart - I am in favor of progressing this way as well. Also verifying the fix on macOS. Thanks Patrick as usual. Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 7a895ec4205659038aa95941b65715fed1a3e7be CPU threads: 12; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6-7": https://git.libreoffice.org/core/commit/01fa786b27ac08aff7eb896653103b36bae6bbfe tdf#153306 prevent subpixel shifting of X coordinate It will be available in 7.6.7. 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.