Re: Why does svtools::EditBrowseBox::IsCursorMoveAllowed paint?

Hi Lionel,

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
the screen.

        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.

        Thanks !

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot