Bug 99463 – [Qt] OpenGL rendering is not possible on bots using Xvfb

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Balazs Kelemen]

We need a workaround to be able to land the patches for pixel testing without breaking testing bots that run tests in xvfb-run. Painting seems to be extremely slow with Xvfb.

[Balazs Kelemen]

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

[Balazs Kelemen]

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.

[Balazs Kelemen]

Created attachment 168952 [details]
Patch

[Balazs Kelemen]

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

[Balazs Kelemen]

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

[Early Warning System Bot]

Comment on attachment 168952 [details]
Patch

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

[Jocelyn Turcotte]

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.

[Balazs Kelemen]

(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).

[Jocelyn Turcotte]

(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.

[Jocelyn Turcotte]

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.

[Balazs Kelemen]

Created attachment 169177 [details]
Patch

[Balazs Kelemen]

Created attachment 169188 [details]
Patch

[Balazs Kelemen]

Created attachment 169189 [details]
Patch

[Jocelyn Turcotte]

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/

[Balazs Kelemen]

Comment on attachment 169189 [details]
Patch

Going to land tomorrow when I can watch the bots.

[Balazs Kelemen]

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