[Libreoffice-bugs] [Bug 121963] button flashing - mouse wheel zooming breaks

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=121963

--- Comment #45 from Armin Le Grand <Armin.Le.Grand at me.com> ---
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191030/7220c1b7/attachment.html>