> On Nov. 23, 2011, 11:33 a.m., Lance Corrimal wrote: > > tested the patch in dolphin viewer 3.2.0.22107. works as expected, no > > negative sideeffects that I can see.
sidenote, testing happened exclusively on linux. - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/521/#review1095 ----------------------------------------------------------- On Nov. 23, 2011, 10:22 a.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/521/ > ----------------------------------------------------------- > > (Updated Nov. 23, 2011, 10:22 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > The fix for the flickering mouse cursor consists of 2 parts: > > The first part changes LLView::childrenHandleHover() so that the cursor is > only set if the control itself is blocking the mouse event and not at every > hierarchy level in the control hierarchy. If the cursor would be set at each > level, it would cause a flicker in case the different controls set a > different cursor. This change actually resembles the algorithm used prior the > start of the flickering. > > The second part changes LLToolTip::handleHover() and specifically handles > flickering of the cursor while hovering over the "i"-button of a hovertip. > The general call to LLPanel::handleHover() was changed to be only called if > the tooltip itself does not set the cursor itself. Logging the calls to > LLWindowWin32::setCursor() revealed that if the "i"-button on a hovertop is > hovered with the cursor said method is called twice with different cursors > alternatively. Checking the call stack further revealed that one call is > coming from LLToolTip::handleHover() and the other one from > LLButton::handleHover(). Latter gets invoked if LLPanel::handleHover() is > called. Since nothing is really done here except setting the cursor to > UI_CURSOR_ARROW only ti get then set to UI_CURSOR_HAND if > LLPanel::handleHover() returns, it doesn't make sense to do invoke that > method unless the cursor is not changed in the tooltip itself. So > LLPanel::handleHover() is only invoked if the tooltip does not set the cursor > itself, so that child controls should take care. > > > This addresses bug STORM-1713. > http://jira.secondlife.com/browse/STORM-1713 > > > Diffs > ----- > > doc/contributions.txt a4a5d827c7f5 > indra/llui/lltooltip.cpp a4a5d827c7f5 > indra/llui/llview.cpp a4a5d827c7f5 > > Diff: http://codereview.secondlife.com/r/521/diff > > > Testing > ------- > > Testing was done by myself on Firestorm rev. 24073 > (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/bcc95de39ca9) on > Windows 7 and Lance Corrimal on Dolphin Viewer. Apparently the fix works > without any side-effects > > > Thanks, > > Ansariel > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
