[webkit-dev] Using ref tests for repaint bugs

[Andrei Bucur]

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.

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?

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/20120525/4744c0e9/attachment.html>