Bug 56739 - [Qt] Add option to run-webkit-tests script to enable webgl testing
Summary: [Qt] Add option to run-webkit-tests script to enable webgl testing
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2011-03-21 06:19 PDT by Jarkko Sakkinen
Modified: 2011-03-22 15:10 PDT (History)
4 users (show)

See Also:


Attachments
Initial draft (1.96 KB, patch)
2011-03-21 06:27 PDT, Jarkko Sakkinen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jarkko Sakkinen 2011-03-21 06:19:35 PDT
Layout tests that have WebGL content need the following options for QtTestBrowser: -gl-viewport -graphicsbased -webgl. In order to achieve this run-webkit-tests script needs --webgl option that enables these.
Comment 1 Benjamin Poulain 2011-03-21 06:24:39 PDT
Increasing priority to P2, if we get proper testing of the feature, we might be able to ship it with 4.8 (even if marked experimental).
Comment 2 Jarkko Sakkinen 2011-03-21 06:27:46 PDT
Created attachment 86315 [details]
Initial draft

Is this how I should approach this?
Comment 3 Csaba Osztrogonác 2011-03-21 06:39:01 PDT
Comment on attachment 86315 [details]
Initial draft

View in context: https://bugs.webkit.org/attachment.cgi?id=86315&action=review

If 3D canvas is enabled, old-run-webkit-tests run webgl tests:

if (!checkWebCoreFeatureSupport("3D Canvas", 0)) {
    $ignoredDirectories{'fast/canvas/webgl'} = 1;
    $ignoredDirectories{'compositing/webgl'} = 1;
    $ignoredDirectories{'http/tests/canvas/webgl'} = 1;
}

> Tools/Scripts/old-run-webkit-tests:321
> +  --webgl                         Enable WebGL for test browser

This option enables WebGL for DumpRenderTree, not for the test browser.

> Tools/Scripts/old-run-webkit-tests:1178
> +  push(@configurationArgs, '-gl-viewport -graphicsbased -webgl') if $webgl;

What do we want, pass these parameters to DumpRenderTree, or pass them to the test browser?
Comment 4 Jarkko Sakkinen 2011-03-21 07:18:12 PDT
Dough. I see what you mean. They are now passed to DumpRenderTree . I have to ask a newbie question because I haven't tuned layout tests before so that I learn :) I try to be specific. 

For which layout tests DumpRenderTree is used and for which test browser is used? To be specific, this question can be scoped to LayoutTests/fast/canvas/webgl. I know that there are also pixel tests (that use ImageDiff) but most WebGL related tests do pixel comparison inside JavaScript code.
Comment 5 Jarkko Sakkinen 2011-03-21 07:22:25 PDT
It would be BTW useful to have in the wiki some kind of high-level diagram or flow chart showing how testing infrastructure produces the results. This would be really helpful for outside contributors.
Comment 6 Jarkko Sakkinen 2011-03-21 07:26:44 PDT
Useful flow chart would show how script executes DumpRenderTree, ImageDiff and QtTestBrowser without too many details.
Comment 7 Jarkko Sakkinen 2011-03-21 07:51:23 PDT
Got the basic idea how the testing infrastructure works. Dump render tree gives the layout test controller instance to the test pages and runs the HTML page. QtTestBrowser is used to only show the end results, right? 

For WebGL tests the tests themselves call layoutTestController.overridePreference("WebKitWebGLEnabled", "1"); and this option is currently handled LayoutTestControllerQt.cpp. And for old-run-webkit-tests the snippet that you pasted does the necessary adjustments. I also looked at the QWebSettings class at it enables accelerated compositing by default.

Summa summarum. The patch is irrelevant and everything needed is already there.
Comment 8 Eric Seidel (no email) 2011-03-22 15:10:44 PDT
Comment on attachment 86315 [details]
Initial draft

Cleared review? from attachment 86315 [details] so that this bug does not appear in http://webkit.org/pending-review.  If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).