[webkit-dev] Rebaselining render tree dumps

[Ryosuke Niwa]

Hi all,

Since this would require a lot of rebaselines anyways, can we also add some
enhancements to DRT?

I propose to an option to dump as text with images.  In many editing tests,
we don't need render tree dumps because we care more about how DOM looks
like before and after editing operations.  However, we also need to verify
that selection and caret are rendered properly on multiple occasions, and
the only way to do this right now is to use a pixel test.  But even then,
dumping render tree is not helpful and almost harmful because it doesn't
tell us how selection / caret are rendered (this can never be tested by
comparing text) and hides some important information about DOM and makes
us rebaseline tests whenever there's slight change (that we don't care) in
the render tree.

James (jamesr) and I talked about this on IRC, and he said this feature will
also be useful for repaint tests and canvas tests.  We can implement this
feature by adding dumpAsTextWithImage to layoutTestController, which forces
DRT to dump as text but also outputs the png image.  For repainting tests,
we can also add dumpRepaintRects to output more information about painting.

- Ryosuke

On Mon, Dec 6, 2010 at 12:30 PM, David Hyatt <hyatt at apple.com> wrote:

> RenderTreeAsTetxt has a large number of hacks in it that have been put in
> over time to keep the dumps from changing too dramatically.  Some of these
> include:
>
> (1) Table cells dump incorrect dimensions and positions.
> (2) Text nodes dump an incorrect bounding box position.
> (3) RenderInlines don't dump their position at all.
> (4) The root layer incorporates overflow when it shouldn't.
> (5) The root element has a RenderLayer when there has been no need for it
> to have a RenderLayer for years.  It only has one in order to not change all
> the layout tests.
>
> In addition there is information not being captured that would be useful to
> include in the dump.  Examples of this include:
>
> (1) Layout and visual overflow for elements.  Right now we're completely
> dependent on repaint tests to catch changes in visual overflow.
> (2) scrollOrigin for the ScrollView and for overflow sections.
> (3) intrinsic padding of table cells.
> (4) Transforms and relative positioning offsets
>
> I'm sure people may have other ideas about things to include in the
> geometry dumps that aren't there right now, so send me your suggestions.
>
> What I'd like to do is have a rebaselining day (probably after the holidays
> in January) where we just shut the tree down and all the ports rebaseline to
> the new format (with the hacks removed and any changes we want to make
> added).
>
> What do people think of this idea?  How can we make sure that a
> rebaselining like this goes smoothly?
>
> dave
> (hyatt at apple.com)
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101207/05fccacf/attachment.html>