Community
Participate
Working Groups
The currently handlers for WM_MOUSEWHEEL in both Scrollable and Widget assume that the delta value for the scroll event will always be a multiple of OS.WHEEL_DELTA, or 120. Windows Vista changes this behavior, making WM_MOUSEWHEEL send "fractional" wheel deltas, which are slightly smaller than that. Watching the WM_MOUSEWHEEL events demonstrates that Vista frequently sends more WM_MOUSEWHEEL events with smaller deltas - for example, a delta of 90 followed by a delta of 60. SWT needs to handle these smaller fractional scroll events. Note that not all mice will cause this effect - it's only been observed in "smooth scroll" mice. Generic mice with the traditional "click"-style wheel that effectively send button presses for scrolling up and down will continue to send OS.WHEEL_DELTA increments.
Created attachment 72296 [details] Patch against latest SWT to support fractional deltas I've created a patch against the current CVS version of SWT to handle fractional wheel deltas. Essentially it just stores the fractional amounts, holding onto them until a full OS.WHEEL_DELTA is encountered and then it functions as normal.
Felipe, didn't you recently have some trouble with your mouse on Vista. Note that the patch adds a field to Scrollable that we would probably put in Display.
See http://msdn2.microsoft.com/en-us/library/ms645617.aspx for a description of fractional deltas.
I found a good article about this: http://msdn2.microsoft.com/en-us/library/ms997498.aspx If we decide to implement smooth scrolling I think we would have to handle fractional lines, in this case the fix would be tottaly different. see Bug 67137. The other option is the patch (save the fractional part and add it to the delta of the next message). The patch is a bit incomplete, according to the article: "The remainder must be zeroed when the wheel rotation switches directions or when window focus changes."
Daniel Potter, what is your mouse ? If you plug the same mouse to a WinXp box you don't get "fractional" wheel deltas ?
It's a Microsoft "Wireless IntelliMouse Explorer 2.0", and no, it didn't occur under Windows XP with the same mouse - although I haven't tried it on the same computer with the OS being the only variable. The only other information of note is the use of Microsoft's IntelliPoint 6 software, although it happened under Vista before I installed IntelliPoint. (At least, I think it did - I haven't tried uninstalling it, and I'm pretty sure one of the reasons I installed it was that the scroll wheel was working erratically in a bunch of programs, Eclipse included. A lot of programs have this problem.)
Daniel, I got a Logitech Revolution and unfortunately this mouse does not send fractional deltas. I don't think I'll get approval to order a "Microsoft Wireless IntelliMouse Explorer 2.0" so I'll write the code I'll give it to you for testing. Can you help us with that ?
Sorry, I meant to respond to this literally a month ago. (A lot of stuff happened around the 4th and then I've been meaning to respond since.) I can help test the bug, although it would be helpful if someone could point me to documentation on how to set up SWT out of CVS, since I sort of faked my way through that when trying to create the original patch.
There are instructions on how to run SWT from CVS on the website. http://www.eclipse.org/swt/cvs.php
Daniel, do you think this problem is causing Bug 205648 ? When you scroll at normal speed do you get the same problem they get ?
Daniel, in http://www.microsoft.com/hardware/oempartners/ProductList.aspx?Type=Mouse I found "IntelliMouse Explorer 4.0A", is that the mouse you have ?
Fixed in HEAD > 20071109
*** Bug 212642 has been marked as a duplicate of this bug. ***
I had issues with my free-spin (otherwise called "smooth scroll", which is a very bad name considering the actual behavior) mouse (logitech MX revolution), and I suggest you re-consider this fix. Basically this mousewheel isn't working at all with any of the implementation (tested 3.3 as well as 3.4M4, which includes this bug fix). Bug detail: - scrolling amount is a short (maximum 273 lines = SHORT_MAX/120) - using free spin, a single scroll event can easily scroll more than 10 lines - swt Scrollable implementation generates n LINEDOWN messages per scroll event - eclipse java editor can't consume those events faster than Scrollable is generating them - the result being: o eclipse uses full CPU when scrolling this mode o scrolling ends tens of seconds after you stop the wheel (because of the loop) o because the WM_MOUSEWHEEL isn't consumed fast enough, Win32/Logitech drivers generates less messages with even bigger values (hence making the situation even worse) o short overflow isn't handled in Win32/Logitech message generation, and when the SHORT_MAX is reach, the amount suddendly gets negative, making the scrolling the other way (as I said, highly unusable) So one overflow bug in Win or Logitech side (didn't check further) who never thought the short limit could be reached with click-by-click mousewheels. But more importantly, mousewheel message in SWT should be consumed in one go, and not changed to X LINE(UP/DOWN). That's fine for the usual 120/240 amounts you get with click-by-click devices, but don't count on it any longer (no standard Win32 application does). I attached the working little patch I did for my 3.3.1.1 eclipse plaform for reference, but don't expect a lot from it (apart from being simple), as it's a dirty hack probably breaking a lot of other applications. Some comments about this patch and logitech devices: - MX Revolutions base wheel amounts in free-spin are -80 for down and 180 for up (different probably because spinning the wheel downwards is easier) - those aren't exact values and they can differ with acceleration setup in logitech driver - the 9/4 ratio (180/80) that you see is a personnal touch because I don't like the difference between up/down amounts, and I wanted to hack a way around it (not configurable in logitech driver) - what my patch does is that I send only one LINEUP/LINEDOWN message, but when handling it in wmScroll(), I actually scroll by the required (dirtily saved) amount, and both skips the rounding to line number (could replace your "remaining" fix that I don't find so clean either) and the multiplication of messages - best solution to me would be to entirely avoid the LINEUP/DOWN messages and really implement the wmMouseWheel, but my Win32/SWT knowledge didn't allow me to do that Result seems fully working (today was my first day of SWT, so I probably missed a lot of things, let me know), and I can finally scroll through pages and pages of java code. (overflow bug from logitech remains but only if I set the acceleration at max value, and that's not really a useful setup anyway). Thanks for reading, I'm available to validate any fix you might find to this problem.
Created attachment 86994 [details] Proof of concept patch for free-spin logitech mousewheels
Francois, thanks for the comments and patch. But you post them in the wrong bug. I've copied it to Bug 184063.
