Closed
Bug 1511419
Opened 6 years ago
Closed 3 years ago
Clean up the way FrameLayerBuilder transfers clips and ASRs to the layer tree
Categories
(Core :: Web Painting, defect, P3)
Core
Web Painting
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox65 | --- | affected |
People
(Reporter: botond, Unassigned)
References
(Blocks 1 open bug)
Details
While investigating bug 1501342, Markus and I realized that the way FrameLayerBuilder converts from the way clips and ASRs are represented in Layout code, to the way they are represented in the Layers API, could use some cleanup.
Markus described to me the two representations, and I wrote a little Rust programs that models them and converts between them:
https://github.com/theres-waldo/clip-asr-processing
The idea is to have FrameLayerBuilder perform the conversion more like that Rust program (at a high level).
Some specific notes based on discussions with Markus:
- ContainerState:mContainer{ScrollMetadata,Compositor}ASR
can go away. Usages can generally be replaced with
mContainerASR.
- ContainerParameters::m{ScrollMetadata,Compositor} ASR
can likewise go away.
- NewLayerEntry::mScrollMetadataASR needs to stick around.
- Some correspondences between FLB and the Rust code which
may not be obvious:
- The scrolled clip handling corresponds to the use of
layerClipChain in ProcessDisplayItems().
- The fixed-pos handling is done in FixUpFixedPositionLayer().
- The loop over scroll metadata corresponds to
SetupScrollingMetadata(). The starting point of the loop
is the first scroll metadata (scrollsWith, adjusted for
any scroll clips). The ending point of the loop is what
the parent layer scrolls with.
Updated•6 years ago
|
Priority: -- → P3
Reporter | ||
Comment 1•3 years ago
|
||
WONTFIXing as FrameLayerBuilder is going away.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•