vcl/osx/salnativewidgets.cxx | 16 ---------------- 1 file changed, 16 deletions(-)
New commits: commit 898d5d470e24a55556f2fb244fec24df33ba8855 Author: Patrick Luby <[email protected]> AuthorDate: Fri Dec 8 14:34:46 2023 +0100 Commit: Patrick Luby <[email protected]> CommitDate: Fri Dec 8 15:39:24 2023 +0100 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 <[email protected]> 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];
