It can noticed that a frame skips in the very beginning of panning in many places (home screen, gallery, settings, etc.). This is more obvious when you pan slowly and when the content is first moved, you notice a noncontinuous jump of the content even you just moved the finger by 1 or 2 pixels. This creates a sluggish feeling of the UI. Attached screen shots are the results of panning in settings app. Both are the result of slow dragging downwards with flash repainted area on. In the first screen shot, the first repainted area is of 7 pixels wide. That's the source of the feeling of the frame skip effect. Ideally, in slow panning, the result should be like the 2nd screen shot with very thin stripes showing that the scrolling is smooth. I got this result by applying a workaround in BrowserElementScrolling.js. I think this should be the result as long as we have HW resource. The problem is both software and hardware issue: - On my unagi, touch panel doesn't report movements during initial movement of my finger. I need to move about 7 pixels so that the driver starts to report touch moves. The symptom is not present on another unagi. We may report this issue to partner for a change in this behavior. - The gesture detectors also could be changed (gecko and gaia): don't use absolute touch positions to calculate each the movement during panning. Use deltas instead might be a better solution. The movement of the content doesn't need to catch up with the movement of the finger. Take gallery for example, enter the single-picture mode, and slowly swipe the finger, you can see a big skip when the next picture started to pan in. The "skip" amount is far larger than the HW threshold.

This drops the first move in panning to avoid the problem.

Marking blocking-basecamp? because I think we should provide user smooth panning experience.

We discussed this in triage and tossed around the idea that we'd ship with this if it was the last bug we had :) That being said, should this block bug 780341? Any thoughts here, cjones?

This is more of a meta bug. We need to triage specific instances of the problem, which can be the result of multiple issues.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #6) > This is more of a meta bug. Okay, making it a meta bug and clearing the nom. This could probably be a dupe of bug 780341 but I guess this is more general.

Firefox OS is not being worked on