> On Dec. 8, 2011, 1:09 p.m., Lance Corrimal wrote: > > I'm finding that in a viewer with the r2 version of this patch the mouse > > pointer flickers through at least three different states in rapid > > succeession when you hover it over your opened inventory and your inventory > > is still loading. > > I'm pretty sure it didn't do that with the previous version.
on a viewer with the older patch the mouse pointer flickers too in this situation, but by far not as pronounced. - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/521/#review1116 ----------------------------------------------------------- On Dec. 5, 2011, 2:43 p.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/521/ > ----------------------------------------------------------- > > (Updated Dec. 5, 2011, 2:43 p.m.) > > > Review request for Viewer and Richard Nelson. > > > Description > ------- > > 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 a984f7ffeb4b > indra/llwindow/llwindow.h a984f7ffeb4b > indra/llwindow/llwindow.cpp a984f7ffeb4b > indra/llwindow/llwindowheadless.h a984f7ffeb4b > indra/llwindow/llwindowmacosx.h a984f7ffeb4b > indra/llwindow/llwindowmacosx.cpp a984f7ffeb4b > indra/llwindow/llwindowmesaheadless.h a984f7ffeb4b > indra/llwindow/llwindowsdl.h a984f7ffeb4b > indra/llwindow/llwindowsdl.cpp a984f7ffeb4b > indra/llwindow/llwindowwin32.h a984f7ffeb4b > indra/llwindow/llwindowwin32.cpp a984f7ffeb4b > > Diff: http://codereview.secondlife.com/r/521/diff/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 Hiller > >
_______________________________________________ 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
