Description: There is no longer smooth scrolling. The scrolling is taking place in delayed jumps of the number of rows specified in the mouse settings (Logitech), which also has smooth scolling enabled Steps to Reproduce: 1. Load a speadsheet (in this case 506 x Y, fairly simple, only with numbers and a few simple calculations) 2. Navigate the spreadsheet by using the mouse wheel Actual Results: No smooth scrolling Expected Results: Smooth scrolling as in all other programs Reproducible: Always User Profile Reset: No Additional Info: Module: SpreadsheetDocument OS: Windows 11 Pro 22H2 OS is 64bit: yes Logitech Setpoint 6.90.66 driver 6.00.115 This is the version working well after uninstalling 7.5.2.2: Version: 7.4.6.2 (x64) / LibreOffice Community Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: threaded
You say this is not seen in 7.4. Can you try an unstable version, Win-x86_64@tb77-TDF from https://dev-builds.libreoffice.org/daily/master/current.html ? If you see the problem in it, copy also the Help - About info from it. Do you see it with a new, blank spreadsheet as well? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
This version, does not exhibit the problemm Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 61b41646c5a93ca24f2c9f143cdb0da2c9258989 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded This version does Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: threaded but not in an empty sheet
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to bugs from comment #2) > This version, does not exhibit the problemm > > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 61b41646c5a93ca24f2c9f143cdb0da2c9258989 > CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: > win > Locale: da-DK (da_DK); UI: en-US > Calc: CL threaded > > This version does > > Version: 7.5.2.2 (X86_64) / LibreOffice Community > Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 > CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: default; VCL: win > Locale: da-DK (da_DK); UI: en-US > Calc: threaded > > but not in an empty sheet I see that when you tested 7.6, it was using your graphics card to render the UI with Vulkan, while your 7.5 was not. It was also using OpenCL to process formulas, but that is probably irrelevant. You could do some last experiments with 7.6 (separately): - deactivate Tools - Options - LibreOffice - View - Use Skia for all rendering and test - deactivate Tools - Options - LibreOffice - OpenCL - Allow use of OpenCL and test If the problem comes back, you can attach an example spreadsheet that shows the problem. If you can't reproduce the problem in any way in 7.6, I think this could be closed as worksforme.
Created attachment 186805 [details] Sheet displaying sluggish display
7.6: With Skia: no problem. Without Skia: sluggish performance. No change observed with/without Opencl
(In reply to bugs from comment #5) > Created attachment 186805 [details] > Sheet displaying sluggish display Probably my computer (i7-6700K, virtual machine) is too fast to notice anything. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3ec73488e447a693a14a773a7fb96938036c0324 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
It must be a programming issue e.g. starting to employ special HW features not generally available. Two program versions on the exact same hardware (AMD Ryzen 5 3600) exhibit different results. The i7-6700 is similar to my AMD Ryzen 5 cpubenchmark.net Intel Core i7-6700K @ 4.00GHz vs AMD Ryzen 5 3600 Single Thread Rating(% diff. to max in group) 2513(-2.2%) 2569(0.0%) CPU Mark(% diff. to max in group) 8949(-49.7%) 17797
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 61b41646c5a93ca24f2c9f143cdb0da2c9258989 CPU threads: 12; OS: Windows 10.0 Build 22624; UI render: default; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded Even with only 50 lines in the sheet, there are noticable delays This below in a VMware virtual machine using Linux Mint 21.1. It does not display any sluggishness Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Thus the problem is most likely a Windows 11 version problem. (Libreoffice is reporting the OS as Windows 10)
The problem cannot be reduced to one particular speadsheet without extensive testing of many spreadsheets.
Please don't change the summary if you don't know what you are doing.
I did not test, but there is a scrolling bug with 4K monitor, what is your resolution?
Same behaviour as previously in 7.5.8.2 and 7.6.4.1. Without Skia sluggish performance, but not due to CPU overload. With Skia smooth performance. I don't know about 4K monitors, but they behave probably the same or even worse.
I can confirm that this behavior still takes place in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded as well as Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 206384 [details] Screenshot showing Skia locked in Disabled state on Windows 11.
Created attachment 206385 [details] Screenshot showing Skia enabled but falling back to Raster.
Created attachment 206386 [details] Skia log confirming RenderMethod: raster.
<Technical Diagnostic Summary> • OS: Windows 11 Pro • Version: 2026.x (current build) • Skia Status: Fails to initialize GPU acceleration (Locked as Disabled - See my attachment: "Screenshot showing Skia locked in Disabled state"). • Raster Fallback: When forced to Enable, log confirms software-only rendering (See my attachment: "Screenshot showing Skia enabled but falling back to Raster"). • skia.log Content: RenderMethod: raster; Compiler: Clang (See my attachment: "Skia log confirming RenderMethod: raster"). <Detailed Request> I'd like to request that the development team reassess the "Unconfirmed" status of the jerky/sluggish scrolling in Calc. As a user who transitioned from macOS to Windows 11 for professional compatibility, I am encountering a significant UX gap that makes LibreOffice a distinct outlier among the "Big 4" spreadsheet applications (Excel, OnlyOffice, Google Sheets). As demonstrated in my attached screenshots, the Skia interface remains locked in a disabled state even when global rendering options are toggled. Furthermore, the attached skia.log reveals that even when forced, the system falls back to Raster (CPU) rendering. This confirms that the current suggested workarounds are ineffective on modern hardware, leaving the jerky row-snap scrolling as the only remaining behavior. I urge the team to elevate Meta Bug 98754 and investigate why the Windows 11 VCL is failing to provide smooth scrolling, forcing a fallback to sluggish software rendering.
In my previous comment, I erroneously listed the version as 2026.x. The correct version being tested is 25.8.5.2 (x86_64). The reported rendering failure and jerky scrolling persist on this specific build.
(In reply to Ken from comment #19) > In my previous comment, I erroneously listed the version as 2026.x. The > correct version being tested is 25.8.5.2 (x86_64). The reported rendering > failure and jerky scrolling persist on this specific build. Can you test with 26.2? In it, Skia is mandatory on Windows.
Created attachment 206440 [details] Updated Skia log from v26.2.2.2 confirming Vulkan initialization (RenderMethod: vulkan)
<Update> Version 26.2.2.2 - Vulkan Active but Jerky Scrolling Persists I have successfully upgraded to 26.2.2.2 and confirmed that the Vulkan engine is now active (see attached updated skia.log). <Test Results> • Despite Vulkan being correctly initialized on my Intel UHD 630, the "jerky" row-by-row snapping persists. • The behavior is identical whether using the mouse wheel or dragging the scrollbar; both remain "stepped" rather than fluid. <Competitive Cross-Test> I performed a side-by-side comparison using the exact same .ods file in OnlyOffice on this hardware. OnlyOffice provides perfectly fluid, pixel-smooth scrolling, whereas LibreOffice 26.2 remains significantly jerky. This demonstrates that the hardware is capable of smooth rendering for this dataset, but the bottleneck remains within the LibreOffice scrolling logic.
(In reply to Ken from comment #22) > • Despite Vulkan being correctly initialized on my Intel UHD 630, the > "jerky" row-by-row snapping persists. But there is no smooth scrolling support in Calc yet. The request for that is bug 40917. Besides that, is there anything out of the ordinary with the scrolling?
Thank you for clarifying that pixel-perfect scrolling (Bug 40917) is not yet implemented in Calc. Having read the thread under Bug 40917, I understand that nothing is beyond the standard row-snapping. However, as a user transitioning from Excel, the lack of Bug 40917 implementation is significantly more noticeable in LibreOffice because the transition between rows feels "heavy" or delayed compared to the fluid logic of OnlyOffice / Google Sheets on the same hardware. Now that we have confirmed Skia/Vulkan is active and working (per my log), I will follow Bug 40917 for future updates. Thank you again for your help.
Testing the original "ElGasVnd.ods" sample above (attachment #186805 [details]), I see no performance problem with: Version: 26.2.1.2 (X86_64) Build ID: 8399f6259d8c87f40e7255cdb3c9b958f5e08948 CPU threads: 8; OS: Linux 6.19; UI render: default; VCL: gtk3 Flatpak Calc: threaded I only see the usual "it scrolls row-by-row, not pixel-by-pixel" bug #40917. Yet, the original reporter titled it with words like "sluggish" and later said in comment #13 that this is about a performance problem, so there were apparently two issues in one. In comment #9, they pointed out that the issue was not occurring in a Linux virtual machine, only on Windows. I guess this would be consistent with the fact that I haven't been able to experience it on my end on Linux.
I would suggest retitling this to be about the slow scrolling performance specifically when running with Skia on Windows, mark it as blocking bug #146014, and "See also" bug #167425 and others blocking the Scrolling-Performance metabug.
This issue can be reproduced in older versions of LO (on Windows, _without_ Skia) by opening attachment 186805 [details] from comment 5 and using the mouse wheel to scroll up/down. In that sense, this report should be at least set as NEW. Having said that, newer versions of LO require Skia. So, although there is an underlying issue, maybe this report will result in WONTFIX anyway(?).
(In reply to Jeff F. from comment #26) > I would suggest retitling this to be about the slow scrolling performance > specifically when running with Skia on Windows, mark it as blocking bug > #146014, and "See also" bug #167425 and others blocking the > Scrolling-Performance metabug. It's the other way around: with Skia there is no problem and Skia these days is mandatory on Windows, so this can be closed.