blink渲染知识四 - layout basics

Posted by DaveHyatt onFriday, August 10th, 2007 at 2:01 pm

When renderers are first created and added to the tree, they haveno position or size yet. The process by which all of the boxes havetheir positions and sizes determined is called layout. Allrenderers have a layout method.

Rendertree创立后，renderer没有坐标和尺寸，需要layout来计算

void layout()

Layout is a recursive operation. A class called FrameViewrepresents the containing view for the document, and it also has alayout method. The frame view is responsible formanaging the layout of the render tree.

There are two types of layout that the FrameView canperform. The first (and by far the most common) is a layout of theentire render tree. In this case the root of the render tree has itslayout method called and then the entire render tree gets updated.The second type of layout is constrained to a specific subtree of therender tree. It is used in situations where the layout of some smallsubtree can’t possibly affect its surroundings. Right now thesubtree layout is only used by text fields (but may be used byoverflow:auto blocks and other similar constructs in the future).

FrameView维护了一个rendertree, 他对应了一个document,他有layout函数来完成真个tree的layout操作，是递归的。FrameView的layout操作有2种：1是fulllayout整棵树，2是只layoutsubtree.

TheDirty Bits

Layout uses a dirty bit system to determine whether an objectactually needs a layout. Whenever new renderers are inserted into thetree, they dirty themselves and the relevant links in their ancestorchain. 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 itcan be queried using the method selfNeedsLayout.Whenever this bit is set to true, relevant ancestorrenderers have bits set indicating that they have a dirty child. Thetype of bit set depends on the positioned status of the previous linkin the chain being dirtied. posChildNeedsLayout is usedto indicate that a positioned child got dirtied.normalChildNeedsLayout is used to indicate that anin-flow child got dirtied. By distinguishing between these two typesof children, layout can be optimized for the case where onlypositioned elements moved.

TheContaining Block

What exactly did I mean by “the relevant ancestor chain”? Whenan object is marked as needing layout, the ancestor chain that isdirtied is based on a CSS concept called the containing block.The containing block is also used to establish the coordinatespace of children. Renderers have xPos and yPoscoordinates, and these are relative to their containing blocks. Sowhat exactly is a containing block?

Hereis the CSS 2.1 spec’s introduction to the concept.

My own way of introducing the concept in terms of the WebCorerender tree would be as follows:

A renderer’s containingblock is an ancestor block of the renderer that is responsible fordetermining that renderer’s position.

In other words when layout recurs down the render tree, it is ablock’s responsibility to position all of the renderers that haveit as their containing block.

The root of the render tree iscalled the RenderView,and this class corresponds to the initialcontaining block according to CSS2.1. Itis also the renderer that will be returned if the renderer()method is called on the Document.

RenderView.h

The initial containing block isalways 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 ispositioned for a document. The black bordered box represents theRenderView, and the grey box represents the entiredocument.

If the document is scrolled, then the initial containing blockwill be moved offscreen. It is always at the top of the document andsized to the viewport. One area of confusion that people often havewith the initial containing block is that they expect it to somehowbe outside the document and part of the viewport.

Hereis the detailed containing block specification in CSS2.1.

The rules can be summarized as follows:

• The root element’s renderer(i.e., the <html> element) will always have the RenderView asits containing block.

• If a renderer has a CSS positionof relative or static, then the containing block will be the nearestblock-level ancestor in the render tree.

• If a renderer has a CSS positionof fixed, then the containing block will be the RenderView.Technically the RenderView does not act as a viewport, so theRenderView has to adjust the coordinates of fixed positioned objectsto account for the document scroll position. It is simpler to justlet the RenderView act like a viewport containing block for this onecase rather than having a separate renderer just for the viewport.

• If a renderer has a CSS position of absolute, then thecontaining block is the nearest block-level ancestor with a positionother than static. If no such ancestor exists, then the containingblock will be the RenderView.

The render tree has two convenience methods for asking if anobject 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 toboth absolute and fixed positioned objects in CSS. The termrelPositioned refers to relative positioned objects in CSS.

The render tree has a method for obtaining the containing block ofa renderer.

RenderBlock* containingBlock() const

When an object is marked as needing layout, it walks up acontainer chain setting either the normalChildNeedsLayoutbit or the posChildNeedsLayout bit. The isPositionedstatus of the previous link in the chain determines what bit getsset. The container chain roughly corresponds to the containing blockchain, although intermediate inlines are still dirtied as well. Adifferent method called container is used instead ofcontainingBlock to determine the chain for dirtyingbecause of this distinction.

RenderObject* container() const

layoutIfNeededand setNeedsLayout(false)

The layoutIfNeeded method (similar in terminology toAppKit’s displayIfNeeded method) is a convenient shorthand fortelling 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 leavingthe layout method, so that future layout calls won’t mistakenlythink that the object is still dirty.

Anatomyof a Layout Method

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);

}

We will drill into specific layout methods in future articles.