Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 807881 - Doesn't handle lots of wheel scroll events very well
Summary: Doesn't handle lots of wheel scroll events very well
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk3
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-29 02:33 UTC by Adam Williamson
Modified: 2012-04-22 04:21 UTC (History)
3 users (show)

Fixed In Version: gtk3-3.4.1-1.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-22 04:21:18 UTC
Type: ---


Attachments (Terms of Use)

Description Adam Williamson 2012-03-29 02:33:46 UTC
This may be a bit of a "Doctor, it hurts", but I figured it was worth asking.

I just bought a new mouse. It has a scroll wheel that can be converted between 'clicky' and 'smooth', and can be rolled very very fast in either of these modes.

If I go to a window where I have lots of room for scrolling - say, my inbox... - and just roll the wheel as fast as I can and let it roll, it seems like X (or it may be higher up the stack, I don't really know, I'm on GNOME on F17) doesn't really handle it very well. It does two or three fairly big 'jumps' as the wheel spins, no kind of smooth scrolling at all. If I get really naughty and do a big fast spin downwards, then a big fast spin upwards, then another big fast spin downwards, I can effectively block input for several seconds while X tries to sort out all the scroll events.

I mean, obviously, I can just...not do that. But I figured it was worth reporting just to see if it's felt worth improving the handling of large amounts of wheel scroll in rapid succession. Should be easy enough to reproduce. Using xorg-x11-drv-evdev-2.7.0-2.fc17.x86_64 , and it was the same with 2.7.0-1.

Comment 1 Peter Hutterer 2012-03-29 22:38:31 UTC
do you see the delay when you run xev or xinput test "device name"? or do you just see it in real-world applications?

please attach a evemu recording of the events too.  http://people.freedesktop.org/~whot/evemu/

Comment 2 Adam Williamson 2012-03-30 17:04:23 UTC
hey, lookit that. xev seems to handle it pretty well. I noticed the effect in Evo and my desktop is GNOME, so let's move this to GTK+, which seems like the next logical suspect.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Fedora Update System 2012-04-14 02:47:25 UTC
gtk3-3.4.1-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/gtk3-3.4.1-1.fc17

Comment 4 Fedora Update System 2012-04-14 17:49:39 UTC
Package gtk3-3.4.1-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gtk3-3.4.1-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-5899/gtk3-3.4.1-1.fc17
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2012-04-22 04:21:18 UTC
gtk3-3.4.1-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.