[webkit-dev] How to interpret repaint test results?
simon.fraser at apple.com
Thu Feb 9 10:33:13 PST 2012
On Feb 9, 2012, at 7:03 PM, Xianzhu (Drew) Wang 王显著 wrote:
> I searched code and found that the repaint rects are only enabled and used on Mac. Chromium just paint the gray mask in layoutTestController.display() and let the later repaints to clear the mask automatically. Haven't check how other platforms do, but I think the different implementations cause different pixel expectations and extra efforts of maintaining them.
> How about just dumping the repaint rects as text?
I'd suggest adding layoutTestController.repaintRectsAsText() or something, so that tests can do whatever they like with the data.
I still think that repaint rects should show in pixel results, because that makes it much easier to spot correct and incorrect behavior.
> Moreover, based on this we could also dump the repaint rects of composited layers so make some tests feasible (for example, https://bugs.webkit.org/show_bug.cgi?id=75638).
Yes, that would help.
> On Wed, Feb 8, 2012 at 11:55 PM, Simon Fraser <simon.fraser at apple.com> wrote:
> On Feb 9, 2012, at 12:16 AM, Xianzhu (Drew) Wang 王显著 wrote:
> > I'm confused with the expected results of some repaint tests, for example, fast/repaint/fixed-scroll-simple.html. The expected pixel result (platform/mac/fast/repaint/fixed-scroll-simple-expected.png) is all masked by dark gray. Does this mean that no part of the page is repainted? However, the test seems to expect that some part of the page is repainted so that the red box is fully covered by the green box and is not left on the page. What did I miss?
> Repaint tests now make use of code in FrameView::repaintContentRectangle(), which records which rectangles were repainted, but only via calls to this method.
> I'm guessing that scrolling does invalidate, but not via FrameView::repaintContentRectangle().
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev