Closed Bug 775452 (multi-apzc) Opened 8 years ago Closed 6 years ago
Support multiple asynchronously-panned subframes
I think xul-fennec may have been the first browser to do this, but since then everyone else has caught up. We're temporarily behind again. We can build on the new AsyncPanZoomController and the code we implemented for xul-fennec to do this. We assign IDs to scrollable frames, create an apzc for them, set that apzc on their Layers, and request repaints by frame ID. We'll want to batch the repaint requests by top-level content frame (mozbrowser), to avoid perf issues and glitchy gfx.
8 years ago
Brad says we shipped Firefox for Android without this and that it's not awful :) Not a blocker for now.
blocking-basecamp: ? → -
Depends on: 775459
Major content use case and needed for competitive parity. Best way to reliably get 60fps scrolling in something like contacts list.
Before making a plan for apzc, we should revisit the prior art from xul-fennec, since we'll want to build on similar principles and reuse some of the code. A lot of it is still in the tree as a reference. Some DNA that lives on from that is LAYER_ACTIVE_FORCE, and FrameMetrics::*Scrollable() helpers. Original work was bug 605618 and bug 618975. The way things worked was pretty elegantly simple, IMHO. 1. On the content side, scrollable frames we wanted to be async-pannable were assigned a special ID  to their IContent. Gecko did this "automatically" according to simple heuristics. 2. FrameLayerBuild gave async-pannable frames their own layer. We tagged those layers with the magic ID, through FrameMetrics. All this was forwarded to the "compositor thread". 3. Upon receiving touchstart, the "UI thread" would perform a hit test using the FrameMetrics in the shadow layer tree . The display list for the hit test was built "in reverse" from the shadow tree. A stack of scrollable frames under the point was returned to the caller. 4. The frontend chose a victim frame to pan. The frontend would set up a displayport for the victim frame  and change its scroll offset by sending message-manager messages to content-side FE JS. 5. Content-side FE code would look up the right elements to pan/set displayport by looking them up through the magic ID . Then it would manipulate the DOMElement(s) appropriately.  http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#439  http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#1709  http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#327  http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#1573
The "diff" I want to apply for apzc is fairly minimal 1. Same. 2. Same. 3. Same, except that the code performing the hit test will be APZC. Because we'll want to use this for fennec, where the UI thread is java, we can't reuse "native" display-list hit testing. (AFAIK.) There's a catch here in that we need to create new APZCs for newly-seen async-pannable layers , and "GC" old ones that no longer appear in the tree. 4. Same, except we'll choose a victim APZC and set it as the event-series "capturer". Dump input events into apzc and run existing code. 5. Same, except that the content agent will be the gecko content controller. I'm not sure yet whether it will be better to share one for all frames in a window or have one per scrollable frame. A complication that will arise on b2g is that we'll have OOP async pan-zoom frames that contain other async pan-zoom frames ... that live in other processes. And recursively :D. The above plan should work fine for all those case though.  APZCs are fairly heavy-weight so we may want to do something smarter, but we can revisit that later.
The reason this is tracked independently of bug 775456 is that we could make all scrollable frames async pan-zoom by default in some contexts, like xul-fennec used to. mobilesafari behavior is opt-in for subframes, though.
Does someone have an example URL where this would apply?
If we choose to make it default for subframes, or just iframes, (which is what we would do while developing the feature), this works http://people.mozilla.com/~cjones/scrolling.html If we choose opt-in for non-iframe subframes, then use the same page but make some frames -moz-overflow-scroll:touch or whatever magical CSS incantation we choose in bug 775456.
Adding bug 776030 as a dependency. With respect to Fennec, I've discussed this with BenWa and Brad, and it looks like the plan is to ensure any work that happens here is compatible with Fennec, which we can test locally once bug 776030 is done. We may need to do some additional work on the Fennec <-> APZC glue as we go along, but the idea is to be able to test async subframe panning without actually turning on APZC in Fennec in Nightly. Later, once we have fully tested APZC in Fennec and made sure it is ready for prime-time, we can turn it on and we'll get the async subframe panning along with it.
Depends on: apz-fennec
Depends on: 866232
Depends on: 866265
Depends on: 833795
Depends on: 872911
Depends on: 880024
Depends on: 881451
Depends on: 883646
Depends on: 888084
Depends on: 890159
Depends on: 896045
Depends on: 898443
Depends on: 898444
No longer depends on: apz-fennec
Depends on: 903460
Depends on: 907179
Depends on: 907754
Depends on: 898075
Depends on: 912144
No longer depends on: 888084
No longer depends on: 890159
Depends on: 912700
Depends on: 913659
Depends on: 916125
This is pretty much done now.
The comments in gfx/layers/FrameMetrics.h should probably be updated since they directly reference this bug and I assume are no longer true?
Thanks for catching that, I filed bug 930903 to fix it.
No longer blocks: gaia-apzc-2
You need to log in before you can comment on or make changes to this bug.