WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
99463
[Qt] OpenGL rendering is not possible on bots using Xvfb
https://bugs.webkit.org/show_bug.cgi?id=99463
Summary
[Qt] OpenGL rendering is not possible on bots using Xvfb
Balazs Kelemen
Reported
2012-10-16 07:38:17 PDT
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.
Attachments
Patch
(8.86 KB, patch)
2012-10-16 08:23 PDT
,
Balazs Kelemen
no flags
Details
Formatted Diff
Diff
Patch
(6.59 KB, patch)
2012-10-17 07:00 PDT
,
Balazs Kelemen
no flags
Details
Formatted Diff
Diff
Patch
(6.50 KB, patch)
2012-10-17 08:19 PDT
,
Balazs Kelemen
no flags
Details
Formatted Diff
Diff
Patch
(6.50 KB, patch)
2012-10-17 08:22 PDT
,
Balazs Kelemen
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Balazs Kelemen
Comment 1
2012-10-16 08:16:17 PDT
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
Comment 2
2012-10-16 08:19:29 PDT
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
Comment 3
2012-10-16 08:23:07 PDT
Created
attachment 168952
[details]
Patch
Balazs Kelemen
Comment 4
2012-10-16 08:39:34 PDT
Test session finished in 21.5 minutes with this for me on the bot machine.
Balazs Kelemen
Comment 5
2012-10-16 08:51:02 PDT
Of course it won't build on the ews without the dependencies.
Early Warning System Bot
Comment 6
2012-10-16 09:15:52 PDT
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 7
2012-10-16 09:57:16 PDT
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
Comment 8
2012-10-17 02:13:33 PDT
(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
Comment 9
2012-10-17 02:52:56 PDT
(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
Comment 10
2012-10-17 06:44:45 PDT
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
Comment 11
2012-10-17 07:00:21 PDT
Created
attachment 169177
[details]
Patch
Balazs Kelemen
Comment 12
2012-10-17 08:19:46 PDT
Created
attachment 169188
[details]
Patch
Balazs Kelemen
Comment 13
2012-10-17 08:22:36 PDT
Created
attachment 169189
[details]
Patch
Jocelyn Turcotte
Comment 14
2012-10-17 08:56:02 PDT
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 15
2012-10-17 08:58:27 PDT
Comment on
attachment 169189
[details]
Patch Going to land tomorrow when I can watch the bots.
Balazs Kelemen
Comment 16
2012-10-18 08:16:22 PDT
Landed in
http://trac.webkit.org/changeset/131727
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug