On Thu, May 24, 2012 at 3:59 PM, Andrei Bucur <[email protected]>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 <[email protected]> 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 <[email protected]>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 >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
