In the document it is explained about the working of DRT’s.

1. WebKit is an open source web browser rendering engine. It is present in almost all the famous
web browsers. Everything that is not IE, Firefox and Opera is a webkit based Browser.
The most important aspect of WebKit is WebCore’s Rendering Process. When it comes to quality
aspects of rendering process, it is made sure that every single aspect of rendering and lay-out
are tested with a standard set of tests called “Layout tests”. Layout tests are web pages. Layout
tests are used to check the correctness of the renderer. The application that runs these layout
tests and produces Render tree as output is “Dump Render Tree”.
Very chosen few organizations are working on WebKit, and out of them the organizations that
have successfully ported DumpRenderTree can be hand picked. Innominds is a proud to be in
that elite list of organizations that have ported DRT on to a mobile platform (BREW in our case.)
DRT is an app with additional methods and objects that help for testing the layout tests. Render
tree is text representation of what the application thinks its putting up on screen for that
particular html page. The output could be texts or screen shots. The tests that produce text are
called “text based tests,” and the tests that produce screen shots are “pixel based tests”.
For this project, Innominds have successfully ported DumpRenderTree and FrameLoaderClient.
There are two important aspects that deserve a mention of the porting aspects. They are
concept of TESTSERVICE and handling the GBs of data involved in Layout tests. An Engineer
working on Mobile platform doesn’t really enjoy the luxury of GB’s of data storage on
Hardware(FFA). So we had to come up with a framework that addressed both these problems.
Then evolved this TEST SERVICE concept that addressed both the problems along with CONNECT
protocol (a remoting protocol that helps in interfacing applications on Desktop to application
running on Mobile). The layout tests and expected files were combinedly occupying around
1.5GB of memory. We have also written a test service (dumprendertreebmp) that will interact
with DRT Design (mod) and uses “CONNECT” Protocol (connectDRT) to invoke this test service.
On a whole following block diagram gives a top level picture of the flow involved in execution of
layout tests.

2. (PERL)
run-webkit-tests_brew--->old-run-webkit-tests_brew
(TEST COMPONENTS)
connectDRT.exe--->dumprendertreebmp
(DESIGN )
webviewapp--->webrenderer-->DRT
DRT’s working can be best explained by analyzing its output on www.google.com url.
Following is the output and depicts the render tree giving details about their exact layout and
size information.
layer at (0,0) size 800x600
RenderView at (0,0) size 800x600
layer at (0,0) size 800x371
RenderBlock {HTML} at (0,0) size 800x371
RenderBody {BODY} at (8,3) size 784x352 [bgcolor=#FFFFFF]
RenderBlock {DIV} at (0,0) size 784x24
RenderBlock (floating) {DIV} at (0,0) size 377x23
RenderInline {NOBR} at (0,0) size 377x16
RenderInline {B} at (0,0) size 29x16
RenderText {#text} at (0,1) size 29x16
text run at (0,1) width 29: "Web"
RenderText {#text} at (35,1) size 4x16
text run at (35,1) width 4: " "
RenderInline {A} at (0,0) size 42x16 [color=#0000CC]
RenderText {#text} at (39,1) size 42x16

3. text run at (39,1) width 42: "Images"
RenderText {#text} at (87,1) size 4x16
text run at (87,1) width 4: " "
RenderInline {A} at (0,0) size 40x16 [color=#0000CC]
RenderText {#text} at (91,1) size 40x16
text run at (91,1) width 40: "Videos"
RenderText {#text} at (137,1) size 4x16
text run at (137,1) width 4: " "
RenderInline {A} at (0,0) size 32x16 [color=#0000CC]
RenderText {#text} at (141,1) size 32x16
text run at (141,1) width 32: "Maps"
RenderText {#text} at (179,1) size 4x16
text run at (179,1) width 4: " "
RenderInline {A} at (0,0) size 32x16 [color=#0000CC]
RenderText {#text} at (183,1) size 32x16
text run at (183,1) width 32: "News"
RenderText {#text} at (221,1) size 4x16
text run at (221,1) width 4: " "
RenderInline {A} at (0,0) size 54x16 [color=#0000CC]
RenderText {#text} at (225,1) size 54x16
text run at (225,1) width 54: "Shopping"
RenderText {#text} at (285,1) size 4x16
text run at (285,1) width 4: " "
RenderInline {A} at (0,0) size 34x16 [color=#0000CC]
RenderText {#text} at (289,1) size 34x16
text run at (289,1) width 34: "Gmail"
RenderText {#text} at (329,1) size 4x16
text run at (329,1) width 4: " "
RenderInline {A} at (0,0) size 44x16 [color=#0000CC]
RenderInline {U} at (0,0) size 29x16
RenderText {#text} at (333,1) size 29x16
text run at (333,1) width 29: "more"
RenderText {#text} at (362,1) size 4x16
text run at (362,1) width 4: " "
RenderInline {SMALL} at (0,0) size 11x14
RenderText {#text} at (366,3) size 11x14
text run at (366,3) width 11: "x{25BC}"
RenderBlock {DIV} at (0,0) size 784x24
RenderInline {NOBR} at (0,0) size 197x16
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 0x0
RenderInline {SPAN} at (0,0) size 55x16
RenderInline {A} at (0,0) size 44x16 [color=#0000CC]
RenderText {#text} at (587,1) size 44x16
text run at (587,1) width 44: "iGoogle"
RenderText {#text} at (631,1) size 11x16

4. text run at (631,1) width 11: " | "
RenderInline {A} at (0,0) size 91x16 [color=#0000CC]
RenderText {#text} at (642,1) size 91x16
text run at (642,1) width 91: "Search settings"
RenderText {#text} at (733,1) size 11x16
text run at (733,1) width 11: " | "
RenderInline {A} at (0,0) size 40x16 [color=#0000CC]
RenderText {#text} at (744,1) size 40x16
text run at (744,1) width 40: "Sign in"
RenderBlock {CENTER} at (0,24) size 784x328
RenderBlock (anonymous) at (0,0) size 784x152
RenderBR {BR} at (392,0) size 0x18
RenderImage {IMG} at (254,19) size 276x110
RenderBR {BR} at (530,114) size 0x18
RenderBR {BR} at (392,133) size 0x18
RenderBlock {FORM} at (0,152) size 784x64
RenderTable {TABLE} at (0,0) size 784x64
RenderTableSection {TBODY} at (0,0) size 784x64
RenderTableRow {TR} at (0,0) size 784x64
RenderTableCell {TD} at (0,0) size 134x12 [r=0 c=0 rs=1 cs=1]
RenderText {#text} at (0,-3) size 4x18
text run at (0,-3) width 4: " "
Close look of above tree gives a detailed explanation of what it is. We can clearly under-
stand where every element goes, and how much is its size in terms of pixels. That’s what
DumpRenderTree is all about, Every detailed information(in textual form) needed to
draw the element. It gives you color information, dimensions of the element, size of the
element, position of the element.
The tabs in the example are important, it indicates that every elements position is w.r.t its
parents indented element. For example let’s take the RenderTable of the last Ren-
derBlock, it says its position is (0, 0). Infact TableRow and TableCell inside Ren-
derTable also indicate their dimensions as (0, 0). It doesn’t mean all the elements are
starting at (0, 0) it only means they are starting at (0, 0) w.r.t to its parents element posi-
tion.
So, how is this information is used to test the renderer?. Here comes the concept of
baselining. Different targets have different screen sizes, and different platforms could
render differently. Hence we need to baseline before we test on that particular target/plat-
form. And now comes the question what is base lining.
Before we compare the actual and expected results, we first need to generate the expected
outputs for every testcase, and this process is called baselining.
After you base-line we start running the perl scripts that will build and start running the
tests. The test case might produce any of the following output.

5. PASS: when both expected and actual results match.
FAIL: when expected and actual mis-match.
TIMEDOUT: when a test fails to produce an output (typically under 30seconds)
CRASHED: (any test that causes DRT tool to crash)
When we compare, we compare text and we compare images too. This is where a tool
called imageDiff comes in to picture. ImageDiff is used to compare pixel by pixel infor-
mation of an image and checksums too. Checksums and images can be generated by perl
scripts by specifying particular options (typically -p).