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)

defect

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.
Depends on: 1501342
Priority: -- → P3
Blocks: 1514291

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.