(As discussed with hyatt on IRC)
On Windows, users can configure the mousewheel to scroll a particular number of lines per wheel tick (default 3). Safari scrolls 40/3 pixels per line, meaning it scrolls 40 px per wheel tick by default. This matches what happens on Mac, except that Mac wheel events are accelerated, meaning that repeated wheel events are reported as having higher deltas, and thus result in much larger scrolls. On Windows, where this acceleration does not occur, Safari feels like it takes forever to scroll down a page.
Other browsers' behavior varies widely. IE appears to scroll approximately 50 px per line, so ~150 px per wheel tick, or almost 4x Safari's amount. However, IE also animates the scroll, which allows larger scrolls without the eye losing its place; a value this large in Safari feels too jerky. Firefox scrolls based on the actual height of the "current line" as reported by the renderer, leading to bizarre effects like scrolling down and back up not returning users to the same spot, and scroll amounts changing as you travel through a page or across pages.
Google Chrome 1.0 scrolled 40 px per line, about 3x Safari's current value, which felt like a little too much -- a number of users complained about losing their place while wheel scrolling. Given a lack of consistency among other products, I'm just going to try a few values.
In the process I think the scrolling code can be simplified. When scrolling by line, we first consult a member function of the PlatformWheelEvent to decide how many lines to scroll in a wheel tick, and then multiply again later to convert lines to pixels. It seems simpler to just eliminate the line-scrolling type and make wheel scrolls either be pixel- or page-based, and do all necessary conversion for pixel scrolls in the platform-specific code.
Created attachment 28333 [details]
After some experimentation, 100 px/wheel tick felt the best of any value I tried.
Comment on attachment 28333 [details]
I wonder if this will impact any layout tests...
Fixed in r41495.