Bug 99463

At first glance it fixes the slowdown in xvfb-run. I tested it in the bot environment (but not ran all the tests yet).

So the plan is to 1. get an r+, 2. ask Ossy to set env var for every bot, 3. land the two pixel test and this in one.

Created attachment 168952 [details] Patch

Test session finished in 21.5 minutes with this for me on the bot machine.

Of course it won't build on the ews without the dependencies.

Comment on attachment 168952 [details] Patch Attachment 168952 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/14389201

Comment on attachment 168952 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=168952&action=review > Tools/WebKitTestRunner/qt/PlatformWebViewQt.cpp:73 > + if (!isRunningWithXvfb()) { Is there really no way to detect this at runtime? This is like showing a dialog to the user asking if his processor supports 64 bits before launching a 64 bits binary, computers are supposed to be smarter than this. > Tools/WebKitTestRunner/qt/TestInvocationQt.cpp:69 > + if (TestController::shared().mainWebView()->supportsSnapshot()) { I don't understand why you need to define it for every port if you only call it from Qt code.

(In reply to comment #7) > (From update of attachment 168952 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=168952&action=review > > > Tools/WebKitTestRunner/qt/PlatformWebViewQt.cpp:73 > > + if (!isRunningWithXvfb()) { > > Is there really no way to detect this at runtime? This is like showing a dialog to the user asking if his processor supports 64 bits before launching a 64 bits binary, computers are supposed to be smarter than this. I don't see an evident way to detect what X server we are running against, but I will try to find something. Most probably the best I can get up with is to check whether xvfb is running via /proc. > > > Tools/WebKitTestRunner/qt/TestInvocationQt.cpp:69 > > + if (TestController::shared().mainWebView()->supportsSnapshot()) { > > I don't understand why you need to define it for every port if you only call it from Qt code. Ok, I will move it behind PLATFORM(QT).

(In reply to comment #8) > I don't see an evident way to detect what X server we are running against, but I will try to find something. Most probably the best I can get up with is to check whether xvfb is running via /proc. The problem is not xvfb itself but rather that it's slow. So it would be nice to know first why it's slow on xvfb, if it runs in software, etc. There has to be a way to call some Qt/OpenGL function to get caps telling us if it's worth making those snapshot.

After discussion on IRC I'm not sure anymore that there would be a reliable way to detect this from within WebKitTestRunner. It turns out that this is caused by the mesa software rasterizer. So the environment variable is probably the best option we have beside adding a new command line option to WebKitTestRunner and run-webkit-test.

Created attachment 169177 [details] Patch

Created attachment 169188 [details] Patch

Created attachment 169189 [details] Patch

Comment on attachment 169189 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=169189&action=review > Tools/ChangeLog:27 > + of evaulating pixel results if the snapshot is not supported, that is to check s/evaulating/evaluating/

Comment on attachment 169189 [details] Patch Going to land tomorrow when I can watch the bots.

Landed in http://trac.webkit.org/changeset/131727