On Thu, Jul 19, 2012 at 12:39:43PM +0100, Michael Meeks wrote: > 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. (...) >> 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. I have found out that it breaks the repainting of the current record/row (in grid view, the green triangle/arrow that points to the current row). > 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 :-) Yes, same performance advantage for Base and seems it does not break the repainting of the current row indicator. Pushed to master. http://cgit.freedesktop.org/libreoffice/core/commit/?id=9bd5e75b95d7b380f9be95913c949221dc4c0d67 Thanks for the advice! One more question: The Paint() call was preceded and followed by: pTHIS->bPaintStatus = static_cast< sal_Bool > (( GetBrowserFlags() & EBBF_HANDLE_COLUMN_TEXT ) == EBBF_HANDLE_COLUMN_TEXT ); and pTHIS->bPaintStatus = sal_True; respectively. Do these lines still make sense after switching to Invalidate instead of Paint? I guess not, but in doubt I left them. Please advise (or just remove them). Actually, if my guess is right, we can remove the bPaintStatus data member completely, as this code was the only one ever touching it (it is private to the class) -> one horrible hack less. -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
