Mobile/AsyncSubframePanning
< Mobile
Jump to navigation
Jump to search
Goals
Phase 1
- land in 23 (not likely)
- B2G subframe scrolling
- Performance is
- as good as main frame
- subframes can't zoom
- seamed scrolling
Phase 2
- Fennec subframe scrolling
- seamless scrolling
Not doing
- scroll indicators are a non-goal
- not fixing page drift
- concurrently scrolling parents and ancestors
- subframe zooming
Plan
- To dos
- merge B2G APZC into fennec
- multiple display ports
- bind multiple display ports
- hit detection
- transform equation cleanup
- unit tests
- tuning/profiling
- concurrently scrolling subframes
Design
Step 1
Performed in Layout module, Main Gecko thread
- (Bug 866232) Layout (FrameLayerBuilder et al.) builds an initial simple layer tree with the position of the subframes tagged to the best fitting layer
- (See diagram for sample page & layer tree)
Step 2
Performed in the compositor's main thread
- Layer tree update/transaction is received by the compositor.
- Touch event is delivered at (6,51).
- (Bug 775452) Hit detection is performed on a layer tree in reverse depth-first order and matches 1st subframe.
- APZC decides of the appropriate buffer/pre-rendering and sends an IPC message to the main thread with an updated FrameMetrics/display port request.
- (See diagram for sample page & layer tree)
Step 3
Performed in Layout module, Main Gecko thread
- Display port is requested on the subframe in Layout
- (Bug 864447) Layer tree is grown to make room for a layer of the 1st subframe.
- Subframe is painted with a display port allowing Async scrolling. FrameMetrics are updated.
- (See diagram for sample page & layer tree)
Step 4
Performed in the compositor's main thread
- (Bug 866265) APZC can now perform Async panning on new sublayer.
Step 5
- After timeout APZC resets FrameMetrics/display port on the subframe removing the display port, the layer and releasing the memory usage.
Notes and diagram
Bugs
Tracking bug for async subframe scrolling: bug 775452
24 Total; 0 Open (0%); 24 Resolved (100%); 0 Verified (0%);
Tracking bug for allowing Fennec to use APZC: bug 776030
75 Total; 2 Open (2.67%); 71 Resolved (94.67%); 2 Verified (2.67%);
Meetings
2013-04-26
- initial meeting, created phases, goals and overall plan
2013-05-21
- Chris will take the display port work
2013-05-28
- Kats put up patch for disambiguated point classes
- will continue propegating the use of the classes through the
- should be up for review this week
- Chris should start on display ports per scroll frame this week
2013-06-04
- Kats
- propagating type changes to frame metrics and APZC code
- BenWa
- unit tests
- hit testing
- ajones
- multiple display ports
- code already largely supports it
- does metro need subframe scrolling?
- next items:
- hit testing (in progress, owned by BenWa)
- creating and managing APZCs from the frame loader builder (need owner)
2013-06-11
- Getting Jim and Brian up to speed, explaining how things work:
- Going through some of our "older" bugs, figuring out the history of how this came to be.
- C++ version that is now being used in Android, almost working completely
- In depth discussion on what the pieces are, how they work together
- Jim & Brian will work on getting single APZC without subframes on Metro. Primarily Brian.
- This will be based off C++ code which B2G uses, and there may be remaining issues in there for a desktop platform. We have to make sure this is tested as soon as it starts working so that we can flush out any remaining bugs.
- The work that Kats, BenWa, AJones are doing should then just click in place and give us subframe APZC on Metro as well.
2013-06-18
- Kats:
- There is another coordinate system that we have to worry about, and B2G seems to be very broken on high dpi devices. This is what the code looks like as well.
- We don't need high dpi for 1.1, so we probably don't need to uplift this. Need to test these changes, and then we should be OK.
- Benoit:
- On hit testing during the last week. More complicated test cases, with transforms, etc.
- Multiple display ports support in the layout, but it probably already supports it. We just need to use those assumptions and proceed.
2013-06-25
- BenWa:
- Pushed the hit testing on try, failed, sorting it out now.
- will finish hit testing, need to sort out gtest
- Kats:
- Sorted out regressions. Tests for bad transformation equations.
- Ran into CSS transforms problem (rotated iFrame, vertical moves end up being diagonal).
- http://people.mozilla.com/~kgupta/tmp/rotated.html
- This is not blocking shipping, Kats will spend no more that another day to fix it
- Blog post of current coordinate system: https://staktrace.com/spout/entry.php?id=800
- will be finishing up the tests
- then move on to managing display ports
2013-07-02
- done
- BenWa hit testing
- layout assumed that root frames were container frames, which isn't correct
- kats fixed high dpi event delivery
- two code paths (with root APZC and w/o APZC)
- seems like enforcing that there is always a root APZC would be the best route
- next
- BenWa will finish hit testing before going on PTO
- when he gets back from PTO, hook up hit testing
- Kats will make sure that there is no code assumeing that there is only one APZC
- will require making APZC owned by layer tree not compositor parent, compositor parent will hold a reference to layer tree
- Kats will defer continuing to work on input event transformation
2013-07-09
- done
- Kats
- We can have multiple PZCs now
- How do we (uniquely) identify scrollable layers? Need to use the layer ID and the scroll/frame ID, and presshell ID to guard against page navigation changes.
- Threading problem is under control by creating a separate tree of APZC instances that shadows the layer tree that is walkable on the UI thread
- This will tie in with dzbarsky's work
- BenWa
- Creating the scroll info layers is done, will be landed today
- Not much else to do at this point, blocked on kats