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 <hy...@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 > (hy...@apple.com) > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev