Closed
Bug 822402
Opened 12 years ago
Closed 11 years ago
Fling friction is different for sync and async scrolling
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-basecamp:-)
RESOLVED
WORKSFORME
blocking-basecamp | - |
People
(Reporter: ajones, Assigned: ajones)
References
Details
(Keywords: b2g-testdriver, unagi, Whiteboard: UX-P?)
Attachments
(1 file)
5.34 KB,
patch
|
cjones
:
feedback+
|
Details | Diff | Splinter Review |
1. Fling on the settings (sync) 2. Fling on the browser (async) Expected result: Settings fling should feel the same as browser fling Actual result: Browser fling feels heavy and slow
Updated•12 years ago
|
Component: Gaia → Gaia::Browser
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → ajones
Updated•12 years ago
|
blocking-basecamp: ? → -
Updated•12 years ago
|
Whiteboard: UX-P?
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•12 years ago
|
||
Assignee | ||
Comment 2•12 years ago
|
||
Comment on attachment 694689 [details] [diff] [review] Fling faster and show what you've got The patch increases the fling speed but forces the scroll offset to overlap the painted region. This means that you can fling off the painted region but when it gets an update notification it forces back to the painted region. This dramatically reduces empty screen during fling problems.
Attachment #694689 -
Attachment description: Bug 822402 - Fling faster and show what you've got; r=cjones → Fling faster and show what you've got
Comment on attachment 694689 [details] [diff] [review] Fling faster and show what you've got Works great! Doug, do you have cycles to review?
Attachment #694689 -
Flags: review?(bugzilla)
Attachment #694689 -
Flags: feedback+
Comment 5•11 years ago
|
||
Comment on attachment 694689 [details] [diff] [review] Fling faster and show what you've got Review of attachment 694689 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/ipc/AsyncPanZoomController.cpp @@ +1082,5 @@ > return requestAnimationFrame; > } > > +gfx::Point CalculcateRectDistance(const gfx::Rect& aRect1, const gfx::Rect& aRect2) { > + gfx::Point point; I'd prefer to call this distance. @@ +1100,5 @@ > +void AsyncPanZoomController::ShowSomethingIfWeHaveNothing(const FrameMetrics& aViewportFrame) > +{ > + gfx::Rect visibleRect(mFrameMetrics.mScrollOffset, > + gfx::Size(mFrameMetrics.mCompositionBounds.width, > + mFrameMetrics.mCompositionBounds.height)); mScrollOffset and mCompositionBounds are in different units. @@ +1106,5 @@ > + gfx::Rect(aViewportFrame.mDisplayPort.x * aViewportFrame.mDevPixelsPerCSSPixel, > + aViewportFrame.mDisplayPort.y * aViewportFrame.mDevPixelsPerCSSPixel, > + aViewportFrame.mDisplayPort.width * aViewportFrame.mDevPixelsPerCSSPixel, > + aViewportFrame.mDisplayPort.height * aViewportFrame.mDevPixelsPerCSSPixel) + > + aViewportFrame.mScrollOffset); With the conversion to device pixels, mDisplayPort*mDevPixelsPerCSSPixel is in different units than mScrollOffset.
Attachment #694689 -
Flags: review?(bugzilla)
Assignee | ||
Comment 6•11 years ago
|
||
nrc has fixed the disparity.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
(In reply to Anthony Jones (:kentuckyfriedtakahe) from comment #6) > nrc has fixed the disparity. Hello Jones: Is there any patch that nrc could provide ?
You need to log in
before you can comment on or make changes to this bug.
Description
•