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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
