[opensource-dev] Review Request: STORM-1713: Mouse pointer flickers when hovering over any active/clickable UI item

[Lance Corrimal]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/521/#review1116
-----------------------------------------------------------


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.

- Lance Corrimal


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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111208/c5746a7d/attachment.htm