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.

Sign up for GitHub

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

fix: typos in JSWrappers and DisplayTree #112

Merged
merged 1 commit into from
Jan 5, 2025
+5 −5
Merged

fix: typos in JSWrappers and DisplayTree #112

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/Deep Dive/Architecture/JSWrappers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ which has an inline pointer to the JS wrapper for the main world if one was alre
## JS Wrapper Lifecycle Management

As a general rule, a JS wrapper keeps its underlying C++ object alive by means of reference counting
in [JSDOMWrapper](https://github.com/WebKit/WebKit/blob/main/Source/WebCore/bindings/js/JSDOMWrapper.h) temple class
in [JSDOMWrapper](https://github.com/WebKit/WebKit/blob/main/Source/WebCore/bindings/js/JSDOMWrapper.h) template class
from which all JS wrappers in WebCore inherits.
However, **C++ objects do not keep their corresponding JS wrapper in each world alive** by the virtue of them staying alive
as such a circular dependency will result in a memory leak.
Expand Down
8 changes: 4 additions & 4 deletions docs/Deep Dive/Layout & Rendering/DisplayTree.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,11 @@ Layout Formatting Context display tree and related functionality (aka "LFC Displ

The **display tree** is intended to be a fully-resolved, isolated tree that is suitable for painting and hit-testing.

*Fully-resolved* means that all style values have been resolved to the values use for painting. For example, colors in the display tree are those which result from the application of visited link rules, and from the application of `-apple-color-filter`.
*Fully-resolved* means that all style values have been resolved to the values used for painting. For example, colors in the display tree are those which result from the application of visited link rules, and from the application of `-apple-color-filter`.

*Isolated* means that a display tree is a stand-alone data structure that can be painted without reference to data structures share with layout. For example, the display tree does not use `RenderStyle` once built, but constructs its own display styles at tree-building time.
*Isolated* means that a display tree is a stand-alone data structure that can be painted without reference to data structures shared with layout. For example, the display tree does not use `RenderStyle` once built, but constructs its own display styles at tree-building time.

All the geometry in the display tree is already in painting coordinates: pixel snapping happens at tree building time.
All the geometry in the display tree is already in painting coordinates: pixel snapping happens at tree-building time.

In general the tree has been designed to push as much of the complexity to tree-building time as possible, so that painting is fast.

Expand Down Expand Up @@ -98,7 +98,7 @@ Clipping is a source of complexity in the display tree because CSS clipping does

At tree-building time `Display::TreeBuilder` keeps track of containing blocks, so for boxes which initiate out-of-order painting (i.e. those which are the root box of a `Display::StackingItem`) `Display::BoxFactory` can ask the containing block for the clip that should be applied.

Clips are store in `Display::BoxClip` which tracks an intersection rect, and, if necessary, a set of rounded rects needed to apply border-radius clips from ancestors. `Display::BoxClip` objects are shared between parent/child `Display::BoxModelObject` objects that share the same clip (i.e. have no overflow of their own).
Clips are stored in `Display::BoxClip` which tracks an intersection rect, and, if necessary, a set of rounded rects needed to apply border-radius clips from ancestors. `Display::BoxClip` objects are shared between parent/child `Display::BoxModelObject` objects that share the same clip (i.e. have no overflow of their own).


## Scrolling
Expand Down