Revert "Related: tdf#155266 force flush after drawing native scrollbars" libreoffice-24-2-branch-point

This reverts commit 5ff701226b00963312cb2a78e77966d012b79c82.

Reason for revert: Tester reports no change in behavior after the commit.

Change-Id: Ic6d9f4834c7c6e3fae34d132298b335f433df280
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160470
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>

1 files changed, 0 insertions, 16 deletions

diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx
index a50735bf4628..8a7e81fd5d86 100644
--- a/vcl/osx/salnativewidgets.cxx
+++ b/vcl/osx/salnativewidgets.cxx
@@ -757,22 +757,6 @@ 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];