Community
Participate
Working Groups
Firefox 9.0 Chrome 16 Mac OS X 10.6.8 1. Open the editor on a large file. 2. Use the mouse wheel to scroll up and down. Each "tick" of the wheel moves the viewport by approx. 1/4 of one line. It takes a long time to browse through a file at this speed. On my Windows machine, the same action scrolls the viewport by about 5 lines.
On the Mac in other applications, single click scrolling is similarly slow but relies on the quick scrolling to increase rate at which the editor is advancing (TextEdit, Mail, Looking at the comment in textView.js _handleMouseWheel: I did some experimenting with Safari and Chrome with a MS Mouse and the trackpad. In Safari 5.1.1 MS Mouse -> e.wheelDeltaY -> scrolling down varies -12, -32, -48, -72, -180, -228, etc depending on velocity of your scrolling on the wheel so multiples of 12 Trackpad -> e.wheelDeltaY -> scrolling down varies -3, -9, -18, -126, -234, etc depending on velocity of your track pad two finger scrolling In Chrome 15.0.... MS Mouse -> e.wheelDeltaY -> scrolling down varies -120, -240, -360, etc depending on velocity of your scrolling on the wheel so multiples of 120 Trackpad -> e.wheelDeltaY -> scrolling down varies -3, -9, -18, -126, -234, etc depending on velocity of your track pad two finger scrolling So the comment: "In Safari, the wheel delta is a multiple of 120. In order to convert delta to pixel values, it is necessary to divide delta by 40." Only seems accurate for Chrome with non-Apple mice/trackpads, and NOT Safari? Changing line 2258 to denominatorY = 10 makes scrolling in Chrome more responsive when trying to scroll fast with the mouse wheel. If the wheelDeltaY is not divisible by 120 this has no effect (trackpad). Does not address Firefox it is a different code path. Thoughts?
(In reply to comment #1) > Thoughts? I will try this out hopefully tomorrow. For me this is losing game, Silenio and I tried quite a few different denominators in the past but there is always a new version or a new mouse that breaks our 'guess'. I just wish deltaY was consistent across platforms/browser/version.
ok, well I have an MS Mouse and several Apple things if you need.
(In reply to comment #2) If there's no consistent fix, maybe we could get the user to calibrate it by scrolling an area of known height with the wheel. Then save the result as a pref somewhere. This would obviously only be valid for one platform/browser though. Just a crazy/future idea.
I tested chrome/firefox/safari with these with 3 mouses apple mouse apple magic mouse ms mouse (IntelliMouse) apple magic mouse was fast on all browsers apple mouse maybe a bit slow on firefox, not bad ms mouse slow on all browsers, the problem seems that the acceleration is too small. Ken, using the trackpad, is the current scrolling good ?
(In reply to comment #1) > > So the comment: > > "In Safari, the wheel delta is a multiple of 120. In order to convert delta to > pixel values, it is necessary to divide delta by 40." > I think we were talking about Safari 4 here. If you read the rest of the comment it says: * In Chrome and Safari 5, the wheel delta depends on the type of the * mouse. In general, it is the pixel value for Mac mice and track pads, * but it is a multiple of 120 for other mice. There is no presise * way to determine if it is pixel value or a multiple of 120. Mark, what mouse are you using ?
(In reply to comment #5) > Ken, using the trackpad, is the current scrolling good ? Yes, the trackpad has acceleration so it can be as slow or as fast as needed. In all of Safari, Firefox and Chrome.
(In reply to comment #6) > Mark, what mouse are you using ? It was a Microsoft mouse.
(In reply to comment #4) > (In reply to comment #2) > If there's no consistent fix, maybe we could get the user to calibrate it by > scrolling an area of known height with the wheel. Then save the result as a > pref somewhere. I was reading about recent changes to the CodeMirror editor, and apparently it now does something similar to this automatically: > Self-adjusting, non-invasive scroll prediction > It does several things. First, it contains a number of crude, hard-coded, > browser-detected constants to use as a first approximation of wheel-delta-to-pixels rates. > > Then, it listens to wheel events, but never calls preventDefault on them or does > scrolling in response to them. Instead, it responds by setting a timeout to observe > the amount of pixels that the wheel event did scroll the content, and uses that to > tweak its delta-to-pixel rate at run-time. http://marijnhaverbeke.nl/blog/a-pathological-scrolling-model.html
Made some changes to base scrolling rate on elapsed time in between individual scrolling events. Fixed in master.
I didn't know how to re-open this, so I've created a new bug here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=535277 I am having this exact same issue. Each "tick" of my mouse scroll wheel is not moving the java code editor by enough pixels. And I have a potential idea for a fix. Historically, the problem was that the mouse hardware would report an arbitrary number of how much the scroll wheel scrolled. For example, it would say "Mouse-Scrolled-Up 40". And then it was anyone's best guess to transform that 40 into a number of pixels. I suggest that at a MINIMUM, one line of text is scrolled per tick, for any non-zero integer reported by the mouse. Right now, I slowly scroll my mouse 10 ticks, and it only moves the editor like 6.5 lines. Why would the user ever want to scroll a half-line of text? It doesn't make sense. Thank you for considering this fix.
