Webkit (Dump Render Tree)
Upcoming SlideShare
Loading in...5
×
 

Webkit (Dump Render Tree)

on

  • 1,337 views

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

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

Statistics

Views

Total Views
1,337
Views on SlideShare
1,333
Embed Views
4

Actions

Likes
2
Downloads
20
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Webkit (Dump Render Tree) Webkit (Dump Render Tree) Document Transcript

  • WebKit is an open source web browser rendering engine. It is present in almost all the famousweb 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 qualityaspects of rendering process, it is made sure that every single aspect of rendering and lay-outare tested with a standard set of tests called “Layout tests”. Layout tests are web pages. Layouttests are used to check the correctness of the renderer. The application that runs these layouttests and produces Render tree as output is “Dump Render Tree”.Very chosen few organizations are working on WebKit, and out of them the organizations thathave successfully ported DumpRenderTree can be hand picked. Innominds is a proud to be inthat 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. Rendertree is text representation of what the application thinks its putting up on screen for thatparticular html page. The output could be texts or screen shots. The tests that produce text arecalled “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 areconcept of TESTSERVICE and handling the GBs of data involved in Layout tests. An Engineerworking on Mobile platform doesn’t really enjoy the luxury of GB’s of data storage onHardware(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 CONNECTprotocol (a remoting protocol that helps in interfacing applications on Desktop to applicationrunning on Mobile). The layout tests and expected files were combinedly occupying around1.5GB of memory. We have also written a test service (dumprendertreebmp) that will interactwith 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 oflayout tests.
  • (PERL) run-webkit-tests_brew--->old-run-webkit-tests_brew (TEST COMPONENTS) connectDRT.exe--->dumprendertreebmp (DESIGN ) webviewapp--->webrenderer-->DRTDRT’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 andsize information.layer at (0,0) size 800x600 RenderView at (0,0) size 800x600layer 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
  • 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
  • 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 whatDumpRenderTree is all about, Every detailed information(in textual form) needed todraw the element. It gives you color information, dimensions of the element, size of theelement, position of the element.The tabs in the example are important, it indicates that every elements position is w.r.t itsparents 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 arestarting 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 ofbaselining. Different targets have different screen sizes, and different platforms couldrender 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 expectedoutputs 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 thetests. The test case might produce any of the following output.
  • 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 toolcalled 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 perlscripts by specifying particular options (typically -p).