[Webkit-unassigned] [Bug 161242] [GTK][Threaded Compositor] Several flaky tests
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Aug 30 06:31:09 PDT 2016
https://bugs.webkit.org/show_bug.cgi?id=161242
--- Comment #12 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #11)
> (In reply to comment #10)
> > Would it be possible to test on the bots without using the software
> > rasterizer?
>
> Yes, please, swrast doesn't work with wayland either, because of
> eglCreateImage being dummy when using the software rasterizer.
>
> > The clipping issues look as if the resizing of the underlying pixmap is not
> > yet complete, or as if just a part of it is rendered.
>
> Why are we using the software path, to not depend on the bot drivers? Maybe
> that's why I could never reproduce those issues. And that would explain why
> all this started when switched to the threaded compositor.
We use swrast because its the best way of ensuring that developers can get consistent results for the layout tests.
Otherwise it will be a nightmare. Think in developers having nvidia cards, or intel ones. With different versions of the drivers, etc.
I have tested the following:
1) Reproduce the problem. I was able to do this at the first try. The trick is run the whole test suite using the same workers as number of CPUs, which is the default. So if you want to reproduce this, don't force any number of workers and simply tun the full test suite.
I did this:
$ Tools/Scripts/run-webkit-tests --no-show-results --no-new-test-results --no-sample-on-timeout --results-directory layout-test-results-xvfb-swrast --debug-rwt-logging --release --gtk
And I got this:
https://people.igalia.com/clopez/wkbug/161242/xresults/layout-test-results-xvfb-swrast/results.html
More information about the webkit-unassigned
mailing list