Why does svtools::EditBrowseBox::IsCursorMoveAllowed paint?
michael.meeks at suse.com
Thu Jul 19 04:39:43 PDT 2012
On Wed, 2012-07-18 at 19:48 +0200, Lionel Elie Mamane wrote:
> Has anybody any clue why svtools::EditBrowseBox::IsCursorMoveAllowed
> needs to call rWindow.Paint()? It causes some pretty stupid behaviour
> in base, namely:
Nope - it looks rather crazy to me. As a general rule - we need to move
away from this "immediate paint" mode - since modern toolkits simply
don't do that; all painting is queued up until idle.
> If I apply the attached patch, things get faster in Base (the
> procedure stops at step 4), but have I broken something else? I don't
> really have a clue.
IMHO we should avoid ~all explicit rendering that is done outside of a
main-loop idle handler / drawing event. In -theory- the widget can
re-render itself without overmuch trouble; so I would guess this is a
pre-optimisation (in a very curious place) to try to re-render less of
I would be inclined to call:
virtual void Invalidate( const Rectangle& rRect, sal_uInt16
nFlags = 0 );
instead of paint there - which -should- defer the rendering until
everything has settled down :-)
Worth checking with that that the grid does re-render as you move the
cursor around I guess.
michael.meeks at suse.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice