Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use border box or layout overflow rect for layout shift tracking #24762

Merged
merged 1 commit into from Aug 1, 2020

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Jul 27, 2020

This CL addresses the following issues of layout shift tracking:

  • Changed visual overflows triggered layout shift report
    (originally filed as crbug.com/1090763).
  • Descendant layout overflows were not included in ancestor's layout
    shift report.
  • Unnecessary descendant layout shift report.
  • Slow visual rect calculation for LayoutInline and LayoutText.

It includes the following changes

  • Track LayoutBoxes and LayoutTexts only.
  • Track both old and new starting points and visual representations
    instead of using location of visual rects as starting points.
  • For a LayoutBox, the local visual representation is the layout
    overflow rect if the LayoutBox has layout overflow and doesn't clip
    overflow. Otherwise use the border box rect.
  • For a LayoutText, suppose its shift causes shift of all contents
    in containing block logically below the LayoutText, and use that
    part of visual representation of the containing block as the visual
    representation of the shift.
  • Map both local starting points and local visual representations to
    the initial containing block and viewport.

This has the following benefits:

  • More accurate starting points and visual representations, conforming
    to the specs;
  • Better performance by
    • avoiding unnecessary layout shift reports of descendants
    • avoiding slow LayoutInline and LayoutText visual rect calculation.
  • sizeof(LayoutObject) is reduced by 16 bytes because now we use the
    previous geometry data in LayoutBoxes for paint invalidation.

Bug: 1108622
Change-Id: I7ebb4e250e7ca2a03b4dadea50034e300e55ad84
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2319538
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#793806}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

@chromium-wpt-export-bot chromium-wpt-export-bot changed the title Use border box rect for layout shift tracking Use border box or layout overflow rect for layout shift tracking Jul 29, 2020
@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-2319538 branch 7 times, most recently from a2ff6a8 to a815dca Compare July 31, 2020 18:39
This CL addresses the following issues of layout shift tracking:
- Changed visual overflows triggered layout shift report
  (originally filed as crbug.com/1090763).
- Descendant layout overflows were not included in ancestor's layout
  shift report.
- Unnecessary descendant layout shift report.
- Slow visual rect calculation for LayoutInline and LayoutText.

It includes the following changes
- Track LayoutBoxes and LayoutTexts only.
- Track both old and new starting points and visual representations
  instead of using location of visual rects as starting points.
- For a LayoutBox, the local visual representation is the layout
  overflow rect if the LayoutBox has layout overflow and doesn't clip
  overflow. Otherwise use the border box rect.
- For a LayoutText, suppose its shift causes shift of all contents
  in containing block logically below the LayoutText, and use that
  part of visual representation of the containing block as the visual
  representation of the shift.
- Map both local starting points and local visual representations to
  the initial containing block and viewport.

This has the following benefits:
- More accurate starting points and visual representations, conforming
  to the specs;
- Better performance by
  * avoiding unnecessary layout shift reports of descendants
  * avoiding slow LayoutInline and LayoutText visual rect calculation.
- sizeof(LayoutObject) is reduced by 16 bytes because now we use the
  previous geometry data in LayoutBoxes for paint invalidation.

Bug: 1108622
Change-Id: I7ebb4e250e7ca2a03b4dadea50034e300e55ad84
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2319538
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#793806}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants