[webkit-dev] Using ref tests for repaint bugs

Žan Doberšek zandobersek at gmail.com
Fri May 25 13:42:11 PDT 2012


On Fri, May 25, 2012 at 9:57 AM, Dominik Röttsches <
dominik.rottsches at intel.com> wrote:

>  Andrei,
>
>
> On 05/25/2012 02:43 AM, Andrei Bucur wrote:
>
> Ojan,
>
>  As Simon states, some repaint tests will likely not be possible to write
> correctly as ref tests, but some of them I think they fit very well in the
> happy-no-pixel-test bucket :). If people decide it's a direction worth
> investigating, I'll give the idea a spin.
>
>
> I'd be interested to hear about your progress. Recently I was facing a
> couple of similar issues:
> https://bugs.webkit.org/show_bug.cgi?id=73409
>
> and then GTK decided to always do repaints before dumping pixel results:
> https://bugs.webkit.org/show_bug.cgi?id=86284
> which might not be the right solution either - so if you come up with
> something more fine-grained - that'd be great.
>

Here's why a repaint is forced for the Gtk port before dumping pixel
results:

Gtk port uses a backing store which is updated every 0.0166667 seconds,
i.e. 60 times per second, a reasonable interval. The problem is that many
tests are structured in the way that they make an alteration that produces
a layout change and then immediately finish. This leaves no time for the
backing store to be updated. It would also be ridiculous to go around
fixing tests by delaying the finish by any amount of time.

Because of that a repaint is forced just before dumping the pixel results
so the dirty regions of the backing store (only those and not the complete
backing store) are updated.

Regards,
Zan


>
>
> Dominik
>
>
> _______________________________________________
> 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/4effeed0/attachment.html>


More information about the webkit-dev mailing list