Closed
Bug 928839
Opened 11 years ago
Closed 10 years ago
Add an API for gecko to kick off APZC scrolling
Categories
(Core :: Panning and Zooming, defect)
Core
Panning and Zooming
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: kats, Unassigned)
References
Details
For bug 928833 (see the second-last paragraph of comment 0) we need an API on the APZC that can be invoked by Gecko to kick off scrolling. I'm not entirely sure what this API will look like, but at this point I'm thinking it would allow Gecko (from the main thread) to pass (a) input events and (b) the desired touch-action behaviour to the APZC.
Updated•11 years ago
|
OS: Gonk (Firefox OS) → All
Reporter | ||
Comment 1•11 years ago
|
||
Vivien pointed us to http://dev.w3.org/csswg/cssom-view/#scrolloptions which provides a possibly-going-to-be-spec API for smooth scrolling. We should try to make our API compatible with that.
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Comment 2•10 years ago
|
||
The smooth scroll CSSOM stuff is being tracked in bug 964097 so I'm removing the dependency here. The stuff in comment 0 is still valid.
Reporter | ||
Comment 3•10 years ago
|
||
We don't need this anymore, i think. For cases where the compositor doesn't know the touch-action behavior yet, gecko can provide that information using the SetAllowedTouchBehavior API that already exists and is currently being used for the touch-action implementation on Metro. Instead of gecko kicking off scrolling directly, the APZ would just hold on to the touch events until it knows what the touch action for those touch points are. The TouchBlock code already takes care of this.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•10 years ago
|
Reporter | ||
Comment 4•10 years ago
|
||
Based on the new usecase described at https://bugzilla.mozilla.org/show_bug.cgi?id=980544#c16 we might need some additional work here.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 5•10 years ago
|
||
After solidifying the design for this feature it looks like once again this is no longer needed. See the design doc at https://github.com/mozilla/gecko-dev/blob/master/gfx/doc/AsyncPanZoom.md for how stuff works.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → WORKSFORME
Comment 6•10 years ago
|
||
I believe this functionality was originally requested in order to allow testing of async scroll performance (for whatever definition of that).
I went over the link from comment 5 briefly, and didn't notice an alternative approach to trigger sych async scroll for such testing.
Are you suggesting to use CSSOM instead? IIRC the scroll duration for CSSOM cannot be controlled neither from CSS nor via the CSSOM DOM API, which makes testing async scroll more complex and dependent on the non-configurable Gecko CSSOM duration. Not impossible though.
Is this what you had in mind?
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 7•10 years ago
|
||
(In reply to Avi Halachmi (:avih) from comment #6)
> Are you suggesting to use CSSOM instead? IIRC the scroll duration for CSSOM
> cannot be controlled neither from CSS nor via the CSSOM DOM API, which makes
> testing async scroll more complex and dependent on the non-configurable
> Gecko CSSOM duration. Not impossible though.
>
> Is this what you had in mind?
This is more or less what I had in mind, yeah. It's true that you cannot control the scroll duration via web content but you can change the layout.css.scroll-behavior.damping-ratio and layout.css.scroll-behavior.spring-constant prefs to control it. Even if we added a Gecko API to trigger an APZ scroll it would just use this prefs behind the scenes so there doesn't seem to be much point in doing that. I feel like you should have all the pieces to be able to test this now on OS X desktop if you want.
Flags: needinfo?(bugmail.mozilla)
You need to log in
before you can comment on or make changes to this bug.
Description
•