Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 334071 - [client][editor]Scrolling in a source file very slow
Summary: [client][editor]Scrolling in a source file very slow
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Client (show other bugs)
Version: 0.2   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 0.2   Edit
Assignee: Silenio Quarti CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-12 06:28 EST by Bruce Mitchener CLA
Modified: 2011-09-01 11:41 EDT (History)
5 users (show)

See Also:

Attachments
fix (8.73 KB, patch)
2011-01-17 12:27 EST, Felipe Heidrich CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Bruce Mitchener CLA 2011-01-12 06:28:15 EST 
Build Identifier: 0.2M4

When I load one of the source files and scroll through it using the trackpad double finger drag, it is very slow.

Grabbing the scrollbar and dragging is fast.

Other scrollareas are fast, like a list of files or identifiers.


Reproducible: Always
Comment 1 Remy Suen CLA 2011-01-12 06:40:46 EST 
Hi Bruce, what browsers have you tested this problem on?
Comment 2 Bruce Mitchener CLA 2011-01-12 08:29:31 EST 
Chrome is bad.

Safari is better, but still feels ... wrong. I think on Safari, the deceleration curve is off.
Comment 3 Felipe Heidrich CLA 2011-01-13 13:54:22 EST 
What version of Chrome are you running (8 I suppose, things where better on Chrome 7) ?

The problem is in the way we interpret wheelDeltaX during "mousewheel" events.
Right now we divided it by 40 to find the pixel value for scrolling. This method was good for Chrome 7 (that is what I remember anyways).

I'm afraid that as far as we are using magic math to interpret the wheelDeltaX we will run in this type of problem. Ideally we should find a way to force the browser to generate "scroll" events from mouse wheel events (like is done in IE and Opera).



I believe Boris show me this problem before.
Comment 4 Silenio Quarti CLA 2011-01-17 11:06:53 EST 
There are two distinct problems here. In Chrome the wheel delta generated is different depending on the mouse. For Mac mice and track pads, the wheel delta is a multiple of 120 and for other mice, the wheel delta is a multiple 3. In Safari, the wheel delta is always a multiple of 120.

The problem in Safari is not caused because of different wheel deltas. It happens because the target of the mouse wheel event is removed from the DOM by updatePage() before the mouse wheel (scrolling) gesture finishes. Some how Safari stops the smooth scrolling if that happens.

As Felipe said, the ideal solution would be to have the browser translate mouse wheel events into scroll events, but due to a bug in Safari, Chrome and Firefox this does not happen when the mouse is over a DIV with fixed positioning (style=fixed). Also, I am not sure the problem in Safari would be solved either.

We will attach a patch that fixes both problems.
Comment 5 Felipe Heidrich CLA 2011-01-17 12:27:26 EST 
Created attachment 186926 [details]
fix
Comment 6 Silenio Quarti CLA 2011-01-17 12:29:32 EST 
Fixed > 20110117.