Confirmed users
490
edits
(Remove some outdated painting content) |
(→Layout: various terminology updates and clarifications.) |
||
| Line 369: | Line 369: | ||
type hierarchy, but the type hierarchy is very different: it includes | type hierarchy, but the type hierarchy is very different: it includes | ||
types like text frames, blocks and inlines, the various parts of tables, | types like text frames, blocks and inlines, the various parts of tables, | ||
and the various types of HTML form controls. | flex and grid containers, and the various types of HTML form controls. | ||
Frames are allocated within an arena owned by the | Frames are allocated within an arena owned by the PresShell. Each | ||
frame is owned by its parent; frames are not reference counted, and code | frame is owned by its parent; frames are not reference counted, and code | ||
must not hold on to pointers to frames. To mitigate potential security | must not hold on to pointers to frames. To mitigate potential security | ||
| Line 385: | Line 385: | ||
Like the content tree, frames must be accessed only from the UI thread. | Like the content tree, frames must be accessed only from the UI thread. | ||
The frame tree should not store any important data. While | The frame tree should not store any important data, i.e. any data that cannot | ||
be recomputed on-the-fly. While the frame tree does | |||
usually persist while a page is being displayed, frames are often | usually persist while a page is being displayed, frames are often | ||
destroyed and recreated in response to certain style changes, and in the | destroyed and recreated in response to certain style changes, and in the | ||
| Line 404: | Line 405: | ||
In addition to tracking a rectangle, frames also track two overflow | In addition to tracking a rectangle, frames also track two overflow | ||
areas: | areas: ink overflow and scrollable overflow. These overflow areas | ||
represent the union of the area needed by the frame and by all its | represent the union of the area needed by the frame and by all its | ||
descendants. The | descendants. The ink overflow is used for painting-related | ||
optimizations: it is a rectangle covering all of the area that might be | optimizations: it is a rectangle covering all of the area that might be | ||
painted when the frame and all of its descendants paint. The scrollable | painted when the frame and all of its descendants paint. The scrollable | ||
| Line 415: | Line 416: | ||
characteristic of the frame itself. The two overflow areas are | characteristic of the frame itself. The two overflow areas are | ||
similar, but there are differences: for example, margins are part of | similar, but there are differences: for example, margins are part of | ||
scrollable overflow but not | scrollable overflow but not ink overflow, whereas text-shadows are | ||
part of | part of ink overflow but not scrollable overflow. | ||
When frames are broken across lines, columns, or pages, we create | When frames are broken across lines, columns, or pages, we create | ||
| Line 428: | Line 429: | ||
at some point want to break that invariant.) | at some point want to break that invariant.) | ||
Continuations are sometimes siblings of each other, and sometimes not. | Continuations are sometimes siblings of each other (i.e. | ||
nsIFrame::GetNextContinuation and nsIFrame::GetNextSibling might return | |||
the same frame), and sometimes not. | |||
For example, if a paragraph contains a span which contains a link, and | For example, if a paragraph contains a span which contains a link, and | ||
the link is split across lines, then the continuations of the span are | the link is split across lines, then the continuations of the span are | ||
| Line 434: | Line 437: | ||
continuations of the link are not siblings (since each continuation of | continuations of the link are not siblings (since each continuation of | ||
the link is descended from a different continuation of the span). | the link is descended from a different continuation of the span). | ||
Traversing the entire frame tree does '''not''' require | Traversing the entire frame tree does '''not''' require explicit traversal | ||
continuations, since all of the continuations are descendants of the | of any frames' continuations-list, since all of the continuations are | ||
element containing the break. | descendants of the element containing the break. | ||
We also use continuations for cases (most importantly, bidi reordering, | We also use continuations for cases (most importantly, bidi reordering, | ||
| Line 448: | Line 451: | ||
If an inline frame has non-inline children, then we split the original | If an inline frame has non-inline children, then we split the original | ||
inline frame into parts. The original inline's children are | inline frame into parts. The original inline's children are | ||
distributed into these parts like so | distributed into these parts like so: The children of the original | ||
inline are grouped into runs of inline and non-inline and runs of | inline are grouped into runs of inline and non-inline, and runs of | ||
inline get an inline parent while runs of non-inline get an anonymous | inline get an inline parent, while runs of non-inline get an anonymous | ||
block parent. | block parent. We call this 'ib-splitting' or 'block-inside-inline splitting'. | ||
This splitting proceeds recursively up the frame tree until all | This splitting proceeds recursively up the frame tree until all | ||
non-inlines inside inlines are ancestors of a block frame with anonymous | non-inlines inside inlines are ancestors of a block frame with anonymous | ||
block wrappers in between. This splitting maintains the relative order | block wrappers in between. This splitting maintains the relative order | ||
between these child frames and the relationship between the parts of a | between these child frames, and the relationship between the parts of a | ||
split inline is maintained using an ib-sibling chain. It is important | split inline is maintained using an ib-sibling chain. It is important | ||
to note that any wrappers created during frame construction (such as | to note that any wrappers created during frame construction (such as | ||
for tables) | for tables) might not be included in the ib-sibling chain depending on | ||
when this wrapper creation takes place. | when this wrapper creation takes place. | ||