Happens when the Control is live (not edit mode) and the mapping is - due to non-linear ViewMapping in Calc - dependent on pixel sies. In these cases, ViewObjectContactOfUnoControl_Impl::positionAndZoomControl is called. That uses adjustControlGeometry_throw where
aTopLeft, aBottomRight change while _rLogicBoundingRect does not (mostly flicker of a single pixel). This is due to different _rViewTransformation being used, dependent on where the paint is compng from (yes, the live Controls' positioning works by lay-positioning these during paint what may lead to an invalidate in the window, but usually only *once*, except for the crude Calc non-linear ViewTransform mapping - ARGH) Key to fix this will be to find out which tranform would be the correct one and which path uses the wrong one... All calls emerge from a single ScGridWindow::DrawContent. Every 2nd paint triggers between two pixel value variations, this can be best seen in ControlHolder::setPosSize One call inside ScGridWindow::DrawContent triggers one pixel value set, another triggers the alternative one. These calls are: DrawRedraw( aOutputData, SC_LAYER_INTERN ); -> smaller/more left pContentDev->SetMapMode(aCurrentMapMode); -> bigger, more right These do then alternate endlessly, because they invalidate different parts. Question is why these lead to different pixel position values... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846940 Title: [upstream] Loop in libreoffice-calc when scrolling to top of spreadsheet To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1846940/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs