Fix for using-mouse-wheel-makes-window-scroll-forever

[linmain]

This fix/optimization attacks one common annoying problem among software: When windows take some time to render themself, and the user scrolls the window up or down, the user will think "hey, scroll faster" and scrolls even heavier. Doing that, the user pushes many wheel events onto the event queue, so that after the user found the right position in the document, the window still processes wheel events and scrolls too far, often over 5 seconds longer than wanted (depending on the rendering complexity).

This patch tries to fix it by measuring the time taken to evaluate and process the current mouse wheel event. When the next event arrives before the current event is processed completely (this is seen by their relative timestamps and the time taken to process the current event), then it is ignored.

This patch has considerably improved the responsibility of the mouse wheel for me, especially with styled text. The patch is attached. It is taken against wx version 2.8.7.

[linmain]

i'm sorry the first file seems not to be the right .patch format. (i'm still a bit n00bish with diff and patch :))
File Added: better_wheel_responding.patch

[linmain]

patch in unified patch format

[wxsite]

transitioning old 'assigned' status to new 'confirmed' status

[vadz]

Thanks, applied to trunk as r54229.

I wonder if this shouldn't be done at wxWindow/mouse wheel event generation level though, it doesn't seem right to do this for wxSTC only as the problem doesn't seem to be STC-specific at all.

I also couldn't really test whether this works as I don't manage to make scrolling in the stc sample to lag (even in a VM) but this seems to do the right thing.

Finally, this can't be applied as is to the 2.8 branch as a new member variable changes the ABI but the patch could probably be modified to use a static variable for it inside wxStyledTextCtrl::OnMouseWheel() itself if you're motivated to do it.

Thanks again!

[DrewBoo]

Replying to vadz:

Thanks, applied to trunk as r54229. I also couldn't really test whether this works as I don't manage to make scrolling in the stc sample to lag (even in a VM) but this seems to do the right thing.

This bugfix introduces two (arguably) more serious bugs.

The core problem that this patch intends to fix is a computer can be too slow to respond to user input fluidly.

This patch solves that problem by selectively ignoring user input. This is a rather harsh solution -- if I slide my finger quickly along the mouse wheel, wxScintilla now behaves as if I clicked the wheel once. All other motion is ignored. This is not in line with the user's intentions and nothing like the mouse wheel behavior in any other application.

A far more serious bug is that wxMouseEvent::GetTimeStamp() can (and does) return a negative number in some environments. In that scenario, all mouse wheel notifications are ignored, always.

A better solution to the original problem would be to accumulate rapidly occurring scroll requests and execute the requests as a single large scroll. Then, a computer that is struggling to keep up with user input still does what the user wants, sacrificing the fluidity of the scrolling instead of sacrificing the entire request.

I could probably propose a patch, if there is interest.

DrewBoo

[vadz]

Replying to DrewBoo:

This patch solves that problem by selectively ignoring user input. This is a rather harsh solution

Yes, absolutely. It's better than nothing but clearly not ideal.

A far more serious bug is that wxMouseEvent::GetTimeStamp() can (and does) return a negative number in some environments.

This is a separate (and serious) bug. What are these environments? This bug should be fixed anyhow.

A better solution to the original problem would be to accumulate rapidly occurring scroll requests and execute the requests as a single large scroll. Then, a computer that is struggling to keep up with user input still does what the user wants, sacrificing the fluidity of the scrolling instead of sacrificing the entire request.

I could probably propose a patch, if there is interest.

We'd be definitely glad to have such patch, TIA!