Revert "Related: tdf#155266 force flush after drawing native scrollbars"
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>
diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx
index a50735b..8a7e81f 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];
