<p> The frame reflow can be logged with the debug capabilities implemented in <ahref="http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsFrame.cpp"><code>nsFrame.cpp</code></a>.
The first line shows the reflow of the viewport (<codeclass="log">VP</code>). This viewport has the address <codeclass="log">00B97C30</code>. It is the initial reflow: <codeclass="log">r=0</code>. Other reflow reasons are: </p>
<table>
<tr><td>1</td><td>incremental reflow</td></tr>
<tr><td>2</td><td>resize reflow</td></tr>
<tr><td>3</td><td>style change reflow</td></tr>
<tr><td>4</td><td>dirty reflow.</td></tr>
</table>
<p>The available width is 9180 twips. The available height is 4470 twips (<codeclass="log">a=9180,4470</code>). The computed width is 9180 twips. The computed height is 4470 twips (<codeclass="log">c=9180,4470</code>). The line count is 856 (<codeclass="log">cnt=856</code>).
<p>
Below this is a line that reads:<p><codeclass="log">tblO 02D7B5F0 r=0 a=8940,UC c=0,0 cnt=870</code></p><p> Here the <codeclass="log">UC</code> shows that on initial reflow the available height for the outer table frame is unconstrained.
<p>
The table cell requires its children to compute the MES. It is reported back from the block as:
<p>Frames with children that overflow the parent will return <code>PR_TRUE</code> from <code>HasOverflowRect()</code>. For these frames
the overflow area is displayed as <codeclass="log">block 025ED8F0 d=8940,1020 o=(0,0) 9180 x 1020</code>. The overflow area is specified as (x,y) origin and width x height.
<p>The previously described technique dumps the data for every frame. Sometimes the log is clearer if only the main frames are shown.
The entries in the reflow log can be controlled on a frame level. For instance adding <code>text 0</code> to the rules in <code>reflow_rules.txt</code> would hide the text entries from the reflow. The display of the following frames can be turned on by adding a line with the frame name and <code>1</code> or turned off by adding a line with the frame name and <code>0</code>:</p>
<p>Once the problem is reduced to a single frame level, placing a breakpoint at <code>DisplayReflowEnterPrint</code> in <ahref="http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsFrame.cpp"><code>nsFrame.cpp</code></a> is a very efficient way to step through
Setting this option via <code>set GECKO_DISPLAY_REFLOW_FLAG_PIXEL_ERRORS = 1</code> enables a verification for each coordinate value that the coordinates are aligned at pixel boundaries.
<tableclass="log"><tr><td>
<pre>
row 0268A594 r=0 a=UC,UC c=UC,20 cnt=870
VALUE 20 is not a whole pixel
cell 0268A6C0 r=0 a=UC,UC c=UC,15 cnt=871
block 0268A764 r=0 a=UC,UC c=UC,UC cnt=872
block 0268A764 d=0,0 me=0
cell 0268A6C0 d=0,0 me=0
row 0268A594 d=UC,20
VALUE 20 is not a whole pixel
rowG 0268A02C d=UC,695
VALUE 695 is not a whole pixel</pre>
</td></tr></table>
<p>
While unaligned values at the entrance of a frame reflow can be ignored, when they appear at the exit of a routine this can cause display errors like stray lines. OS2 is very vulnerable to pixel alignement errors as text is drawn on pixel boundaries.
Setting this option via <code>set GECKO_DISPLAY_REFLOW_INDENT_UNDISPLAYED_FRAMES = 1</code> will cause an advance of the indent even for frames which are blocked via the reflow rules file.
