个人主页https://xugaoxiang.com,微信公众号: Dev_Club 或者搜索 程序员Club
全部博文(229)
分类: LINUX
2011-02-24 22:40:58
When renderers are first created and added to the tree, they have no
position or size yet. The process by which all of the boxes have their
positions and sizes determined is called layout. All renderers have a layout
method.
void layout()
Layout is a recursive operation. A class called FrameView
represents the containing view for the document, and it also has a layout
method. The frame view is responsible for managing the layout of the render tree.
There are two types of layout that the FrameView
can
perform. The first (and by far the most common) is a layout of the
entire render tree. In this case the root of the render tree has its
layout method called and then the entire render tree gets updated. The
second type of layout is constrained to a specific subtree of the
render tree. It is used in situations where the layout of some small
subtree can’t possibly affect its surroundings. Right now the subtree
layout is only used by text fields (but may be used by overflow:auto
blocks and other similar constructs in the future).
Layout uses a dirty bit system to determine whether an object actually needs a layout. Whenever new renderers are inserted into the tree, they dirty themselves and the relevant links in their ancestor chain. There are three unique bits that are used by the render tree.
bool needsLayout() const { return m_needsLayout || m_normalChildNeedsLayout ||
m_posChildNeedsLayout; }
bool selfNeedsLayout() const { return m_needsLayout; }
bool posChildNeedsLayout() const { return m_posChildNeedsLayout; }
bool normalChildNeedsLayout() const { return m_normalChildNeedsLayout; }
The first bit is used when the renderer itself is dirty, and it can be queried using the method selfNeedsLayout
. Whenever this bit is set to true
,
relevant ancestor renderers have bits set indicating that they have a
dirty child. The type of bit set depends on the positioned status of
the previous link in the chain being dirtied. posChildNeedsLayout
is used to indicate that a positioned child got dirtied. normalChildNeedsLayout
is used to indicate that an in-flow child got dirtied. By
distinguishing between these two types of children, layout can be
optimized for the case where only positioned elements moved.
What exactly did I mean by “the relevant ancestor chain”? When an
object is marked as needing layout, the ancestor chain that is dirtied
is based on a CSS concept called the containing block. The containing block is also used to establish the coordinate space of children. Renderers have xPos
and yPos
coordinates, and these are relative to their containing blocks. So what exactly is a containing block?
My own way of introducing the concept in terms of the WebCore render tree would be as follows:
A renderer’s containing block is an ancestor block of the renderer that is responsible for determining that renderer’s position.
In other words when layout recurs down the render tree, it is a block’s responsibility to position all of the renderers that have it as their containing block.
The root of the render tree is called the RenderView, and this class corresponds to the initial containing block according to CSS2.1. It is also the renderer that will be returned if the renderer()
method is called on the Document
.
The initial containing block is always sized to the viewport. In
desktop browsers, this is the visible area in the browser window. It is
also always at position (0,0) relative to the entire document. Here’s a
picture illustrating where the initial containing block is positioned
for a document. The black bordered box represents the RenderView
, and the grey box represents the entire document.
If the document is scrolled, then the initial containing block will be moved offscreen. It is always at the top of the document and sized to the viewport. One area of confusion that people often have with the initial containing block is that they expect it to somehow be outside the document and part of the viewport.
The rules can be summarized as follows:
The render tree has two convenience methods for asking if an object has a position of absolute, fixed or relative. They are:
bool isPositioned() const; // absolute or fixed positioning
bool isRelPositioned() const; // relative positioning
Throughout most of the code the term positioned refers to both absolute and fixed positioned objects in CSS. The term relPositioned refers to relative positioned objects in CSS.
The render tree has a method for obtaining the containing block of a renderer.
RenderBlock* containingBlock() const
When an object is marked as needing layout, it walks up a container chain setting either the normalChildNeedsLayout
bit or the posChildNeedsLayout
bit. The isPositioned
status of the previous link in the chain determines what bit gets set.
The container chain roughly corresponds to the containing block chain,
although intermediate inlines are still dirtied as well. A different
method called container
is used instead of containingBlock
to determine the chain for dirtying because of this distinction.
RenderObject* container() const
The layoutIfNeeded
method (similar in terminology to
AppKit’s displayIfNeeded method) is a convenient shorthand for telling a
renderer to only do a layout if it has a dirty bit set.
void layoutIfNeeded()
All layout methods typically end with setNeedsLayout(false)
.
It is important to clear dirty bits on the renderer before leaving the
layout method, so that future layout calls won’t mistakenly think that
the object is still dirty.
At a high level layout methods usually look something like this:
void layout()
{
ASSERT(needsLayout());
// Determine the width and horizontal margins of this object.
...
for (RenderObject* child = firstChild(); child; child = child->nextSibling()) {
// Determine if the child needs to get a relayout despite the dirty bit not being set.
...
// Place the child.
...
// Lay out the child
child->layoutIfNeeded();
...
}
// Now the intrinsic height of the object is known because the children are placed
// Determine the final height
...
setNeedsLayout(false);
From:
http://www.webkit.org/blog/116/webcore-rendering-iii-layout-basics/
}
We will drill into specific layout methods in future articles.