[webkit-dev] Using ref tests for repaint bugs

[Ojan Vafai]

On Thu, May 24, 2012 at 3:59 PM, Andrei Bucur <andrei.bucur at gmail.com>wrote:

> No, I need a way to force a paint operation, similar to what
> layoutTestController.display() achieves, but without tracking the paint
> rectangles.
>
> Does anyone you find value in adding an optional parameter to display (or
> create another method on LTC) that disables paint rectangle tracking.
>

I don't see any problems with this. Someone more familiar with the paint
code might see issues.


> The main advantage for such a change would be in extending the ref tests
> power to also cover repaint tests (at least a part of them), thus making
> pixel tests less necessary. Repaint bugs appear usually when the  layout
> changes but the old pixels are incorrectly invalidated. By making the
> reference HTML directly identical to the test document after the bug
> triggering changes have been applied, it is pretty certain that the output
> pixels for the reference file will not contain the repaint artifacts
> (there's no repaint operation involved). When running such a test with a
> client that has the bug, it will fail because the test file output will
> have artifacts and the reference output will not. On the other hand, using
> a client with the repaint bug fixed, the pixels output for the test and
> reference files should be identical.
>
> Thoughts?
>

I'm open to experimenting with this, but different ports have very
different repaint schemes (e.g. Chromium merges all the repaint rects into
a large rect). I'm curious how likely a repaint reftest is to work across
ports. If you're willing to investigate converting a handful of repaint
tests over to reftests, that'd be very helpful.

FWIW, you can easily test the reftests on the chromium port by sending a
patch to the EWS via bugzilla since the Chromium-linux EWS runs the layout
tests.

Obviously, if we can convert repaint tests reftests (or, at least have new
repaints tests be reftests), that would be a huge improvement in
maintainability since repaint tests are one of the few categories of tests
where we can't currently use reftests.


> Andrei.
>
>
> On Thu, May 24, 2012 at 11:57 PM, Ojan Vafai <ojan at chromium.org> wrote:
>
>> Do you just need to force a layout at the end of repaintTest, e.g.
>> document.body.offsetHeight;?
>>
>> On Thu, May 24, 2012 at 6:34 AM, Andrei Bucur <andrei.bucur at gmail.com>wrote:
>>
>>> Hello WebKittens,
>>>
>>> I'm trying to simplify the patch for a certain repaint bug (
>>> https://bugs.webkit.org/show_bug.cgi?id=59863 ) by using ref tests
>>> instead of pixel tests.
>>>
>>> The test HTML file should first render the document in state 1 and then,
>>> by modifying the DOM, render it again state 2. The bug appears when
>>> repainting from state 1 to state 2. The expected result HTML for the test
>>> is just a document directly written in state 2 (so there is no transition,
>>> no bug). This should work on all the platforms but there's problem with the
>>> time control between paints for state 1 and state 2 in the test HTML. I've
>>> tried three options:
>>> 1. Use setTimeout() to update the DOM -> I really wouldn't like to use
>>> this because it slows down the test and can be flaky.
>>> 2. Use layoutTestController.display() before modifying the DOM to
>>> trigger a paint -> calling this seems to make the test fail because
>>> display() starts tracking the paint rects which doesn't happen in the
>>> reference document.
>>> 3. Make use of requestAnimationFrame to time the paintings for state 1
>>> and state 2 -> doesn't work directly out-of-the-box because
>>> requestAnimationFrame schedules a full repaint after going into state 2 and
>>> the bug doesn't reproduce anymore.
>>>
>>> Is there a preferred solution to this problem or another one that I'm
>>> missing?
>>>
>>> Thanks,
>>> Andrei.
>>>
>>> _______________________________________________
>>> 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/20120524/4c3d3778/attachment.html>