Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334071

Summary:

[client][editor]Scrolling in a source file very slow

Product:

[ECD] Orion

Reporter:

Bruce Mitchener <bruce.mitchener>

Component:

Client

Assignee:

Silenio Quarti <Silenio_Quarti>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

bokowski, eclipse.felipe, Mike_Wilson, remy.suen, Silenio_Quarti

Version:

0.2

Target Milestone:

0.2

Hardware:

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

Attachments:

Description	Flags
fix	none

Description Bruce Mitchener

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

2011-01-12 06:40:46 EST

Hi Bruce, what browsers have you tested this problem on?

Comment 2 Bruce Mitchener

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

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

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

2011-01-17 12:27:26 EST

Created attachment 186926 [details]
fix

Comment 6 Silenio Quarti

2011-01-17 12:29:32 EST

Fixed > 20110117.