https://bugs.documentfoundation.org/show_bug.cgi?id=152406
--- Comment #36 from Patrick Luby <[email protected]> --- (In reply to Caolán McNamara from comment #35) > For gtk back in the day I recall we struggled with "smooth scrolling" events > with https://bugzilla.redhat.com/show_bug.cgi?id=1367846#c18 and ended up > overwhelmed by scroll events. I wonder if trying the same pattern as the > gtk3 "AsyncScroll" in vcl/unx/gtk3/gtkframe.cxx would be useful. Launch an > Idle on the first scroll event, accumulate the scrolls events and merge > together and and dispatch as one scroll notification when the Idle gets > fired. Thanks for the hint! In my testing, macOS isn't getting flooded as the code in vcl/osx/salframeview.mm is pulling all the pending mouse wheel events in the native queue, coalescing them, and then dispatching the combined change. What is interesting is that the bug becomes easier to reproduce on my MacBook Pro Silicon if I ignore any mouse wheel events that have zero X and Y change (i.e. dispatch less events). But I think I am getting closer. I can now reproduce this bug if I swipe rapidly and repeatedly from right to left for at least 10 seconds. Then I swipe rapidly, the vertical scrollbar and visible rows stop changing, and the horizontal scrollbar's thumb gets shorter and shifts to the right (i.e. more visible columns are added). Also, if I multiple the X and Y by 10K, I can reproduce the bug using Shift-scrollwheel instead of swiping. In other words, it seems you have to jump way out right (maybe past 8K columns?) very rapidly to trigger this bug. Theory: Calc is repeatedly running an idle timer that expands the number of visible columns in the sheet (i.e. a horizontal scroll wheel handler). What is interesting is that after this idle timer adds all columns, all vertical scroll wheel events dispatched in vcl are ignored. Other mouse events and key events are handled normally (even dragged the scrollbar thumb) so my last theory that a long-running job was blocking the main thread was wrong. So I think Calc's idle timer that adds visible columns blocks handling of vertical scroll wheel events until an unknown condition is set. So far, another horizontal scroll wheel event is the only known case that will set this unknown condition. Even adding the maximum 16K columns does not seem to set this condition. @Telesto: thank you for the samples. One sample is repainting the scrollbar in a timer and that helped me come up with my current theory. -- You are receiving this mail because: You are the assignee for the bug.
