https://bugs.documentfoundation.org/show_bug.cgi?id=121963
--- Comment #45 from Armin Le Grand <[email protected]> ---
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 are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
