If I have spreadsheet document with large, multiline cells, I can't scroll to distance equal some part of line. full line is scrolled at once. There is no option in preferences about scrolling by line (as in Excel) and scrolling by pixels (as in Word). Please add such option, or tell me where to find it, if it exists. The original from: (https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/375395)
I believe this is more or less a DUP of "Bug 34689 - UI scroll problem: Cell with dimensions exceeding screen dimensions impossible to work with". @Коренберг Марк: Do you agree? Please file Bug reports with status UNCONFIRMED if your are not absolutely sure that it's not a DUPlicate, that you contributed all required background information, that the problem will be reproducible with information you can provide or that your enhancement request will be accepted! Thank you! May be you can test <http://wiki.documentfoundation.org/BugReport_Details> for submitting bug reports?
Yes, this two bugs are connected. But they are different. My bug specify that scrolling is always jumpy. Bug 34689 is in impossibility to scroll large cells. If smooth scrolling will be implemented, both bugs will be closed. Closing Bug 34689 may be implemented in another way.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Confirmed that the problem is still present with Calc 5.3.2.2. Scrolling by whole lines is jarring and unnatural. And as mentioned, implementing proper pixel-by-pixel scrolling will also resolve https://bugs.documentfoundation.org//show_bug.cgi?id=34689.
*** Bug 98755 has been marked as a duplicate of this bug. ***
set status to NEW since there's an independent confirmation in comment 9
*** Bug 125098 has been marked as a duplicate of this bug. ***
*** Bug 35759 has been marked as a duplicate of this bug. ***
From 3.5.0 builds onward, the multi-line input for the Formula Input Bar (ScInputBarGroup) provides direct editing of a an over height cell including cursor and page movements (provided by the edit engine) IMHO resolving bug 34689. So yes, the Calc sheet rendered to VCL canvas only scrolls by single sheet rows. Note also that the provided scroll bar control (up, down, and thumb slide) also move in full row increments. IIUC more precise/incremental scrolling has been necessary because the entire sheet is the extend of the scroll, millions of cells-thousands of columns and rows. Contrasted to Writer tables, which provide precise/incremental scrolling (and smooth scrolling) Calc sheets are much more complex. Rendering them for more precise scrolling seems desirable but likely non-performant if the entire sheet is being manipulated. Meaning there would need to be a new view shell framework to allow off screen caching of a view port onto the sheet--controlled by the range of visible/working cells. Complex stuff, and requires major refactoring of Calc needing some UX envisioning. But the refactoring (to support some semblance of view ports into a sheet) may be too much for a GSOC project.
(In reply to V Stuart Foote from comment #14) Sorry, unclear > IIUC more precise/incremental scrolling has been necessary because the > entire sheet is the extend of the scroll, millions of cells-thousands of > columns and rows. > rather, more precise/incremental scrolling has been impossible because the entire sheet is the extent of the scroll...
*** Bug 95920 has been marked as a duplicate of this bug. ***
*** Bug 117487 has been marked as a duplicate of this bug. ***
*** Bug 114849 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #14) > Complex stuff, and requires major refactoring of Calc needing some UX > envisioning. What exactly? The requirement is clear (and requested repeatedly in the recent survey [1]). It's expected to scroll per pixel even when the cell exceeds the window size. We have to jump to the top when going into edit mode. But besides I don't see nothing controversial. [1] https://design.blog.documentfoundation.org/2021/10/18/results-from-the-survey-about-libreoffice-calc/
*** Bug 149618 has been marked as a duplicate of this bug. ***
*** Bug 149869 has been marked as a duplicate of this bug. ***
*** Bug 152566 has been marked as a duplicate of this bug. ***
*** Bug 163172 has been marked as a duplicate of this bug. ***
*** Bug 168865 has been marked as a duplicate of this bug. ***
*** Bug 34689 has been marked as a duplicate of this bug. ***
*** Bug 41139 has been marked as a duplicate of this bug. ***
*** Bug 46505 has been marked as a duplicate of this bug. ***
*** Bug 70525 has been marked as a duplicate of this bug. ***
*** Bug 84099 has been marked as a duplicate of this bug. ***
I'm an experienced software developer with no knowledge of this project aside from using it daily. I'm very frustrated with this issue, as most of my tables contain large multi-line cells. I'm afraid it's unrealistic for me to jump into the project and fix this as first contact, but I would appreciate pointers to relevant code to understand the issue and maybe hopefully offer a solution.
(In reply to Maple Wuff from comment #30) > I'm an experienced software developer with no knowledge of this project > aside from using it daily. I'm very frustrated with this issue, as most of > my tables contain large multi-line cells. I'm afraid it's unrealistic for me > to jump into the project and fix this as first contact, but I would > appreciate pointers to relevant code to understand the issue and maybe > hopefully offer a solution. if you run $ git grep -in scroll sc/source/ui/view/ from inside the libreoffice source code, you should see a bunch of places. The ScGridWindow class is where I would start looking. Also $ git log --grep=scroll sc/ will show you commits that have touched scrolling behaviour in calc, and might be useful as code pointers.
Maple: you can email me, if you want to go through the build setup and other first steps in a text chat.
Thank you both very much! I'm going to be extremely busy at least until the 23rd of this month, but I'm looking forward to giving this a try probably next month
Created attachment 206493 [details] Test case (ODS) with high row heights (50 lines per cell) to demonstrate the failure of row-snapping logic.
Created attachment 206494 [details] Test case (XLSX) with high row heights. Provides fluid scrolling in Excel/OnlyOffice, but remains jerky/stepped in Calc.
New Test Cases for Version 26.2 (Windows 11 Pro & KDE Neon 6.6.2) Many thanks for your consideration, but please let me attach two sample files (smoothScroll.ods and smoothScroll.xlsx) to demonstrate how the current "row-snapping" logic creates a functional barrier for professional workflows involving high-density cells (e.g., legal refactoring). <Observations> These files contain rows with 50 lines of text. In LibreOffice 26.2 (tested on both Windows 11 with Vulkan and KDE Neon with kf5/Wayland), it is impossible to scroll to the middle of these cells; the view jumps violently to the next row header. For comparison, the exact same files provide perfectly fluid, pixel-by-pixel scrolling in MS Excel, OnlyOffice, and Google Sheets on the same hardware. I am providing these to illustrate that even with modern rendering backends (Skia/Vulkan) initialized, the lack of smooth scrolling remains a significant competitive gap and a major productivity hurdle for users migrating from other suites. Thank you for your time and attention.
IMHO a distinction should be made between scrolling with GPU hardware acceleration where we could feasibly support by pixel based scrolling and our legacy non-accelerated CPU scrolling where our by-cell/column scrolling only continues to make sense. By pixel (raster for row/column) and any smooth scrolling implementation requires much more robust off-screen caching for double buffering. It makes no sense to attempt that with CPU and cache resources only--but seems a reasonable facet to offload to GPU where skia libs for raster framing are ubiquitous. What prevents us from leveraging our skia / skia Vulkan / skia Metal implementation to buffer the multi-view ports of a calc sheet needed to support by-pixel scrolling? It is dev effort, but it is long overdue to improve the UI/UX.
(In reply to V Stuart Foote from comment #37) > IMHO a distinction should be made between scrolling with GPU hardware > acceleration where we could feasibly support by pixel based scrolling and > our legacy non-accelerated CPU scrolling where our by-cell/column scrolling > only continues to make sense. > > [...] Please don't make GPU acceleration a hard requirement for pixel-based scrolling. I'd really like to see this working in no-GPU/CPU-driven environments like Xvnc or QEMU virtual machines.
(In reply to Kyle Marek from comment #38) > > Please don't make GPU acceleration a hard requirement for pixel-based > scrolling. I'd really like to see this working in no-GPU/CPU-driven > environments like Xvnc or QEMU virtual machines. Sorry really have to disagree. Firmly believe that you and other users, would not like the abysmal performance of CPU only by-pixel scrolling. And see no reason to inflict that on the user base. Rather, if refactored to implement by-pixel movements, we should explicitly exclude the non-GPU accelerated usage--and limit CPU rendering only to legacy by row/ by column movements.
I'd definitely rather have the feature work under Xvnc even if there are performance issues than not have it work at all. I'm not necessarily saying to not take advantage of GPU acceleration when you can, but rather that I don't want the lack thereof to limit the software. If trying to minimize perceived performance issues, please at the very least allow users to choose to go to the advanced settings and forcibly enable scrolling by pixel in unaccelerated environments. For the record, Microsoft Excel scrolls fine in virtual machines and non-GPU-accelerated RDP. So does Google Sheets running in Firefox under Xvnc.
(In reply to Kyle Marek from comment #40) > I'd definitely rather have the feature work under Xvnc even if there are > performance issues than not have it work at all. > > I'm not necessarily saying to not take advantage of GPU acceleration when > you can, but rather that I don't want the lack thereof to limit the > software. If trying to minimize perceived performance issues, please at the > very least allow users to choose to go to the advanced settings and forcibly > enable scrolling by pixel in unaccelerated environments. I don't want to pay the (performance) price for something that I don't need, even if I had the adequate hardware. I'd rather leave my very limited resources available for things that actually impact my work. I understand that other users might need pixel-by-pixel scrolling / movements, so I am not against the potential implementation of it, but in my case I'd rather see that (not-yet-implemented) possibility as an optional (not the default), no matter the hardware, instead of forcibly changing the current default behavior (i.e. cell-by-cell scrolling) towards something that requires more resources. Needs, desires and resources are not always the same for everyone.
I agree with ady (comment #41). In fact, after thinking about it a little more, I think it would be ideal to have a button in the status bar to allow the user to rapidly switch between scrolling by cell vs scrolling by pixel based on what they know is more useful/desirable for them in that moment (regardless of the availability of GPU acceleration for scrolling by pixel).
*** Bug 171591 has been marked as a duplicate of this bug. ***
Created attachment 206669 [details] Simplified test case (15 numbers/cell) to isolate scrolling lag - ODS
Created attachment 206670 [details] Simplified test case (15 numbers/cell) to isolate scrolling lag - XLSX
Created attachment 206671 [details] 60 FPS capture of LibreOffice's stuttering motion
Created attachment 206672 [details] 60 FPS capture of OnlyOffice's fluid motion
I would like to provide additional evidence (video clips) regarding the ongoing "jerkiness" experienced during vertical scrolling in LibreOffice, particularly when compared to other major spreadsheet applications. <Video> Attached are side-by-side recordings of LibreOffice and OnlyOffice capturing this behavior. They were captured with Spectacle at 60 FPS (confirmed via metadata analysis). As demonstrated in the clips, the active "stutter" during continuous movement is clearly visible when compared to the fluid motion of OnlyOffice. <Reduced complexity in the new comparison> In previous discussions, it was noted that complex cell contents might contribute to the lag. To eliminate this variable, I have created new test files (smoothScroll_lite.ods and .xlsx). These cells no longer contain 50 vertical characters; the new files contain only 15 vertical numbers. However, the jerkiness remains obvious and reproducible, even with this significantly reduced data load. <Comparative Performance> To clarify the scope of this issue, I have verified that MS Office, OnlyOffice, and Google Sheets all provide perfectly smooth scrolling experiences under the same system conditions. This suggests the behavior is specific to LibreOffice's current rendering or scrolling logic on certain environments (specifically KDE Neon 6.6.4 in my case). I hope this simplified test case helps the team isolate the bottleneck. I would be grateful for your investigation into the issue at your convenience. I am happy to provide further logs or system specifications if required to help resolve this bug. Thank you for your time and attention in advance.
(In reply to Ken from comment #48) Completely different graphics--comparing apples to oranges. Comparing a Web browser engine to a desktop application. => Invalid OnlyOffice does not follow a Cairo based rendering framework--it (along with the Collabora offerings) implements HTML5 Canvas framework. While LibreOffice is heavily dependent on Cairo with improvements at low-level with SDPR. Unlikely that LibreOffice would move away from Cairo. But SDPR could support pixel based double buffering movements if sufficient dev interest drives it.
Response to V Stuart Foote (re: Comment 14 and the VCL refactoring): Thank you for the technical context regarding the VCL canvas and the complexity involved in refactoring the view-shell to support view-ports. However, from a professional user standpoint, the attached side-by-side videos (OnlyOffice vs. Calc) demonstrate that this 'row-increment' limitation has become a significant functional barrier. For users refactoring complex documentation — such as my work with legislation — the inability to scroll within a tall cell remains disorienting, even when modern backends like Skia/Vulkan are active. I am providing this feedback and the 60 FPS captures to illustrate that, while the 'underwater mechanisms' are indeed complex, the practical outcome is factually a clear competitive gap, compared to other modern suites that have already implemented pixel-perfect scrolling. Thank you for your understanding.
(In reply to Ken from comment #50) Yes, we do understand. But this is unlikely to be addressed anytime soon. However, in addition to OnlyOffice, you should check the offerings for the new Collabora Office Desktop builds. Where IIANM they have refactored soffice, including Calc, to use WebGL/Canvas which by default on Windows will render in WebView2's Chromium instance--so it supports the browser like by pixel scrolling already. I found it very smooth. Given recent TDF noise to resurrect an online flavor might go that direction, but a lot of technical debt and a dearth of devs given political ejection from TDF of the Collabora employed contributors. Meanwhile, the Cairo SDPR would be a much more appealing long term solution to the buffering needed for by pixel scrolling. But again the dev expertise for that went with Collabora.
Created attachment 206705 [details] 60 FPS capture of Collabora Office's stuttering motion.
(In reply to V Stuart Foote from comment #51) Thank you for your advice. Following the suggestion, I have tried Collabora Office 25.04.14.2 on KDE Neon 6.6.4. <Results> I have to say that vertical scrolling remains locked to row boundaries (at a greater extent than LibreOffice). When a cell’s height exceeds the viewport (common in legislative documentation), the 'snapping' makes it impossible to navigate the interior of the cell smoothly. <Rendering Tests> I tested with VCL: gtk3. I also used Expert Configuration to toggle ForceSkia and ForceSkiaRaster. Forcing Skia Rasterization (software rendering) resulted in an application hang/failure to launch, while standard hardware acceleration maintained the jerky behavior. <Cross-App Comparison> Attached is a screencast comparing OnlyOffice (which demonstrates smooth scrolling on the same file) vs. Collabora 25.04. Hope I have provided enough evidence, but please kindly let me know should you require any other information. Thank you for your attention.
(In reply to Ken from comment #53) > (In reply to V Stuart Foote from comment #51) > > Thank you for your advice. Following the suggestion, I have tried Collabora > Office 25.04.14.2 on KDE Neon 6.6.4. > > <Results> > I have to say that vertical scrolling remains locked to row boundaries (at a > greater extent than LibreOffice). When a cell’s height exceeds the viewport > (common in legislative documentation), the 'snapping' makes it impossible to > navigate the interior of the cell smoothly. Sorry, seems like maybe you grabbed the Collabora Office classic (legacy VCL) you should test the current Collabora Office (based on the HTML5 vice WebGL/Canvas implementations as developed by CP for Collabora Office Online ). Snapshots of current 26.04 dev builds in flatpack are here: https://www.collaboraoffice.com/downloads/Collabora-Office-Linux-Snapshot/ the Windows builds are also available either as .appx installer. Or as Zip'd up package (allowing similar mods to a bootstrap.ini to run from $ORIGIN in isolation). https://www.collaboraoffice.com/downloads/Collabora-Office-Windows-Snapshot/ Just verified with a Windows build that the Calc scrolling is not by full cell/column. And that scrolling in Writer is much cleaner with its WebView2 framework. Assume the FlatPack uses HTML5 WebGL canvas and offers similar scrolling. But again, that is not a solution likely to land in LibreOffice anytime soon where refactoring in viewport buffered framing and additional Cairo SDPR implementation would be needed to support by pixel scroll.
(In reply to V Stuart Foote from comment #54) Thank you for the additional information regarding the 26.04 Snapshot. I have now completed the comparison between the "Classic" VCL build and the Flatpak Snapshot on KDE Neon. <Scrolling Performance> You are correct: the 26.04 Flatpak (HTML5/Canvas based) does indeed provide the smooth, pixel-based scrolling I was looking for. It handles the tall cells in my legislative test files without the "row-snapping" jerkiness of the native build. <Professional Limitations> However, while the scrolling is improved, I find the Flatpak implementation's functionality too limited for my current professional requirements (refactoring complex legislative frameworks). The nature of this build lacks the depth and comprehesiveness found in the standard desktop suite. <Conclusion> While the Flatpak proves that smooth scrolling is architecturally possible within the Collabora ecosystem, it currently feels like a sneak-peek version rather than a robust desktop tool. I therefore will continue to use a combination of the current version of LibreOffice and OnlyOffice depending on the task. I kindly encourage the team to continue the motivation to bring this level of scrolling fluidity to the native desktop versions of LibreOffice or Collabora Office. I look forward to a future release where the fully professional functionality of the suite is paired with a user-friendly pixel-perfect scrolling engine. Thank you for your attention.