vcl/osx/salnativewidgets.cxx |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

New commits:
commit 5ff701226b00963312cb2a78e77966d012b79c82
Author:     Patrick Luby <plub...@libreoffice.org>
AuthorDate: Thu Dec 7 14:20:16 2023 -0500
Commit:     Patrick Luby <plub...@libreoffice.org>
CommitDate: Thu Dec 7 22:36:22 2023 +0100

    Related: tdf#155266 force flush after drawing native scrollbars
    
    When scrolling on some Intel Macs either via dragging
    the scrollbar thumb or via swiping the trackpad with two
    fingers, final repaint of scrollbars doesn't appear to
    get flushed to the screen. It appears that scrollbars
    aren't updated and repainted until after a batch of
    native scroll events have been dispatched. On slower
    machines, this lag is long enough that any pending
    forced flushes have already been done so when the timer
    that repaints scrollbars finally fires, the repainted
    scrollbars won't get flushed to the native window until
    the next normal flush which may not occur until seconds
    later.
    
    Change-Id: Iadef6812cd2495a28347560caae81f604c908b51
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160440
    Tested-by: Jenkins
    Reviewed-by: Patrick Luby <plub...@libreoffice.org>

diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx
index 8a7e81fd5d86..a50735bf4628 100644
--- a/vcl/osx/salnativewidgets.cxx
+++ b/vcl/osx/salnativewidgets.cxx
@@ -757,6 +757,22 @@ bool 
AquaGraphicsBackendBase::performDrawNativeControl(ControlType nType,
 
                     CGContextRestoreGState(context);
 
+                    // Related: tdf#155266 force flush after drawing native 
scrollbars
+                    // When scrolling on some Intel Macs either via dragging
+                    // the scrollbar thumb or via swiping the trackpad with two
+                    // fingers, final repaint of scrollbars doesn't appear to
+                    // get flushed to the screen. It appears that scrollbars
+                    // aren't updated and repainted until after a batch of
+                    // native scroll events have been dispatched. On slower
+                    // machines, this lag is long enough that any pending
+                    // forced flushes have already been done so when the timer
+                    // that repaints scrollbars finally fires, the repainted
+                    // scrollbars won't get flushed to the native window until
+                    // the next normal flush which may not occur until seconds
+                    // later.
+                    if (mpFrame && nType == ControlType::Scrollbar)
+                        mpFrame->mbForceFlush = true;
+
                     bOK = true;
 
                     [pBar release];

Reply via email to