Created attachment 201328 [details] Sample ODS This bug can be reproduced with Skia + hardware acceleration enabled, see in Tools -> Options / View: 'Use Skia for all rendering' is enabled, but 'Force Skia software rendering' is not. I only checked under Windows, not sure if it's reproducible under Mac. Open the attached simple spreadsheet file, and starting from A1, keep your down/up arrow key pressed to move about the filled cells (eg. between A1 to A30 and back). => Note how the cell cursor lags behind the actual selected cell while you move the selection over cells with content, indicated by the row highlight. Once you stop, it settles on the correct cell. See attached screencast. This was OK until the beginning of the following range in 7.3, where hardware-accelerated Skia started crashing, and LO switches to Skia software rendering (which doesn't have the bug). The crashing got fixed at the end of the range, which already exhibits the bug: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d5ec688e4b0aa97eed72ed56d53a5d014b59eb63..2a0f2f074dd643b723bfbcc5c96e4f5ee8da87a3 It also got temporarily fixed between the following two commits (a commit and its revert): https://git.libreoffice.org/core/commit/f4c2c7c79cfe4464ac596afda37b8904d06969db author Patrick Luby <plubius@neooffice.org> Thu Sep 21 20:20:33 2023 -0400 committer Patrick Luby <plubius@neooffice.org> Fri Sep 22 15:03:43 2023 +0200 "tdf#157312 Don't change priority" https://git.libreoffice.org/core/commit/5a38e4f9798c5ff247aa57581adf2671485627fd author Patrick Luby <guibmacdev@gmail.com> Sat Nov 09 18:27:35 2024 -0500 committer Patrick Luby <guibomacdev@gmail.com> Sun Nov 10 14:49:01 2024 +0100 "tdf#163734 Revert commit f4c2c7c79cfe4464ac596afda37b8904d06969db Commit f4c2c7c79cfe4464ac596afda37b8904d06969db lowered the Skia flushing priority to solve tdf#157312. But the commit caused the "window will dock in rectangle" border to not be drawn when dragging a dockable window over a dockable position. Surprisingly, tdf#157312 does not reoccur without the commit so it appears that the commit is now unnecessary." CCing Patrick, in case he has an idea about the issue.
Created attachment 201329 [details] Screencast
What version of LibreOffice are you testing with? You are looking at old code. The 2 commits of mine that you are looking at were replaced and for the last few months the "lower priority" code is now in #ifdef MACOSX blocks. So in master back to LibreOffice 25.2.4 (maybe even LibreOffice 24.8.7), Windows and Linux have this timer set to "highest priority".
(In reply to Patrick (volunteer) from comment #2) > What version of LibreOffice are you testing with? > > You are looking at old code. The 2 commits of mine that you are looking at > were replaced and for the last few months the "lower priority" code is now > in #ifdef MACOSX blocks. So in master back to LibreOffice 25.2.4 (maybe even > LibreOffice 24.8.7), Windows and Linux have this timer set to "highest > priority". For example, in vcl/skia/gdiimpl.cxx, I see code like the following on master. Are you using one of the Collabora distro branches?: #ifdef MACOSX // tdf#157312 and tdf#163945 Lower Skia flush timer priority on macOS // On macOS, flushing with Skia/Metal is noticeably slower than // with Skia/Raster. So lower the flush timer priority to // TaskPriority::SKIA_FLUSH so that the flush timer runs less // frequently but each pass copies a more up-to-date offscreen // surface. // tdf#165277 Skia needs to flush immediately before POST_PAINT // tasks on macOS SetPriority(TaskPriority::SKIA_FLUSH); #else SetPriority(TaskPriority::HIGHEST); #endif
In fact, I now remember that Mike Kaganski had done the same thing is you last year and reverted the same old patches. That caused a collection of severe bugs on macOS with Skia/Metal. So, soon after LibreOffice 25.2.0 was released, I added back all of the macOS Skia/Metal timer changes but within #ifdef MACOSX because Skia/Metal on macOS works very differently than Skia/Vulkan on Windows and Linux. Michael Meeks and Noel Grandin were involved at the time because Mike Kaganski reversions (just like you are doing now) broke macOS badly. I definitely think you are working off of very outdated code. It's as if you are repeating the work that Mike Kaganski and I did over the last year. If you need to change anything Windows or Linux, please do not remove the #ifdef MACOSX blocks.
Hmm, can not reproduce the same stutter shown in capture during keyboard scroll down and up positioning the active cell. Neither skia/Vulkan nor skia/Raster rendering. And even CPU only, or CPU with HA is smooth although the movment of active row indicator leads the cell border draw a bit more noticeably non-skia. But this is on a recent dGPU hw, with current skia and Vulkan API support. Will check in a bit to see how it does with more modest iGPU on a 10th gen CPU. =-testing-= Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 28; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded =-hw_dxdiag-= Card name: NVIDIA GeForce RTX 4060 Ti Device Key: Enum\PCI\VEN_10DE&DEV_2803&SUBSYS_51501028&REV_A1 Driver File Version: 32.00.0015.7640 (English) Driver Version: 32.0.15.7640 DDI Version: 12 Adapter Attributes: HARDWARE_TYPE_GPU,D3D11_GRAPHICS,D3D12_GRAPHICS,D3D12_CORE_COMPUTE,D3D12_GENERIC_ML,D3D12_GENERIC_MEDIA Feature Levels: 12_2,12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1,1_0_CORE Driver Model: WDDM 3.2 =-hw_vulkaninfo-= Vulkan Instance Version: 1.4.304 GPU0: VkPhysicalDeviceProperties: --------------------------- apiVersion = 1.4.303 (4210991) driverVersion = 576.40.0.0 (2416574464) vendorID = 0x10de deviceID = 0x2803 deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU deviceName = NVIDIA GeForce RTX 4060 Ti pipelineCacheUUID = a552de6d-1faf-8ad5-bfbe-abbefffa0211
(In reply to Patrick (volunteer) from comment #2) > What version of LibreOffice are you testing with? Sorry, forgot to add: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 497a4090de8a33704df4101fc078a48c4cf71101 CPU threads: 16; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL threaded If you think the code changed at some point and it's worth checking in certain builds, feel free to point to commits.
OK, so on a less robust system with 10th gen iGPU with current driver support, I could reproduce the stutter *only with skia Vulkan rendering* while scrolling the Calc cell cursor selection down and up. No issue skia/Raster, CPU w/HA or CPU only rendering. So seems more a hw/driver resource issue with Vulkan rendering. =-testing-= Version: 25.2.4.3 (X86_64) / LibreOffice Community Build ID: 33e196637044ead23f5c3226cde09b47731f7e27 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded =-hw_dxdiag-= Card name: Intel(R) Iris(R) Plus Graphics Dedicated Memory: 128 MB Shared Memory: 8072 MB Driver File Version: 31.00.0101.2135 (English) Driver Version: 31.0.101.2135 DDI Version: 12 Adapter Attributes: HARDWARE_TYPE_GPU,D3D12_GRAPHICS,D3D12_CORE_COMPUTE,D3D12_GENERIC_ML,D3D12_GENERIC_MEDIA Feature Levels: 12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1,1_0_CORE Driver Model: WDDM 3.1 =-hw_vulkaninfo-= Vulkan Instance Version: 1.3.301 GPU0: VkPhysicalDeviceProperties: --------------------------- apiVersion = 4206807 (1.3.215) driverVersion = 1656919 (0x194857) vendorID = 0x8086 deviceID = 0x8a52 deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU deviceName = Intel(R) Iris(R) Plus Graphics pipelineCacheUUID = 663d6430-6f32-5132-6e3f-6d316a356803
@Aron, can we really claim regression here? Not bibisectable, and seems very system dependent on hw/driver state.
(In reply to Aron Budea from comment #6) > If you think the code changed at some point and it's worth checking in > certain builds, feel free to point to commits. OK. I was confused. Looking at the #else blocks attached to the #ifdef MACOSX blocks in vcl/skia/gdiimpl.cxx, I see the following: mFlush->SetPriority(TaskPriority::POST_PAINT); I would try changing those 2 to the following: mFlush->SetPriority(TaskPriority::HIGHEST); The #ifdef MACOSX blocks don't need to change as using HIGHEST priority on macOS actually causes this bug as well as the docking border bug. For some reason, Windows and Linux always need to high priority timers and macOS needs to be low priority. That is what started all these changes: these same two bugs were occurring on macOS. I think what happened is that when Mike Kaganski first reverted my macOS commits last year, he didn't revert my 2 changes of priority from HIGHEST to POST_PAINT. Then, when I added back the special Skia/Metal handling for macOS. I just moved the POST_PAINT cases into #else blocks. So, changing one or both of the POST_PAINT back to HIGHEST should hopefully get Skia/Vulkan back to where it was before my two commits listed in comment #0.
(In reply to Patrick (volunteer) from comment #9) > So, changing one or both of the POST_PAINT back to HIGHEST should hopefully > get Skia/Vulkan back to where it was before my two commits listed in comment > #0. More background info: my guess is that the reason POST_PAINT is likely causing this and the docking border bug on Windows and Linux is that POST_PAINT priority timers are frequently deferred by the scheduler code in vcl/source/app/scheduler.cxx. On Windows and Linux, only HIGHEST and DEFAULT priorities are not deferred. So any POST_PAINT timers keep getting deferred until you stop typing or dragging.
I've posted a patch if you want to try it out. I don't have access to Windows or Linux so I can't test it: https://gerrit.libreoffice.org/c/core/+/186631
(In reply to Patrick (volunteer) from comment #11) > I've posted a patch if you want to try it out. I don't have access to > Windows or Linux so I can't test it: > > https://gerrit.libreoffice.org/c/core/+/186631 Thanks for the patch, Patrick! I'm happy to test it, but can only do it about a week from now.
Maybe a dup of tdf#121539
(In reply to m_a_riosv from comment #13) > Maybe a dup of tdf#121539 Sure sounds like it to me.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ad59ecf37f847295e99069281d94518f5afedf90 tdf#167059 Revert remaining use of POST_PAINT priority for Skia paint timer It will be available in 26.2.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 Aron Budea from comment #12) > Thanks for the patch, Patrick! I'm happy to test it, but can only do it > about a week from now. Noel gave the patch a +1 so I went ahead and committed it. Hopefully, @V Stuart and @Telesto can test it. But I will wait to backport it until you have a chance to test it. If you find the patch doesn't work for you, I can just revert it.
Forgot to mention that the patch will be in tomorrow's (29 June 2025) nightly master builds for Windows and Linux (there are no macOS changes in the patch): https://dev-builds.libreoffice.org/daily/master/current.html
I don't have a system with Skia/Vulkan support at hand. So I'm unable to test this
(In reply to Telesto from comment #18) > I don't have a system with Skia/Vulkan support at hand. So I'm unable to > test this Skia/Raster on Windows and Linux also use the same Skia timer so maybe you will see some change this bug and/or tdf#121539when using Skia/Raster.
(In reply to Patrick (volunteer) from comment #17) > Forgot to mention that the patch will be in tomorrow's (29 June 2025) > nightly master builds for Windows and Linux (there are no macOS changes in > the patch): > > https://dev-builds.libreoffice.org/daily/master/current.html Tested the 2025-06-20 nightly on a resource limited laptop, iGPU with only 128Mb of video memory 8Gb shared total available. Current WDDM 3.1 level intel drivers and Vulkan 1.3 level support. With skia/Vulkan rendering, still get the stutter scrolling the cell cursor on a calc sheet. No stutter in skia/Raster rendering. And no issue in Vulkan rendering on a more robust system with dGPU and 8Gb video RAM and ~60Gb shared total to work with. Current WDDM 3.2 level nVidia drivers and Vulkan 1.4 level support. This still kind of seems a GPU hw resource issue. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 024053c0c140e1d167a0276f1885a21a160b45ac CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Wanted to test on macOS but Settings > View has `Use hardware acceleration` greyout out and shows a key icon on the left. I have no idea what the icon is trying to communicate to users, no tooltip is showing. A tooltip "requires restart" shows when hovering "use hardware accceleration". This seems rather confusing. Unsure what is expected and how to enable hardware acceleration to try and reproduce the issue.