Skip to content
Browse files

Pull WebGL conformance 2.0.0 suite

  • Loading branch information
MortimerGoro committed Nov 2, 2017
1 parent 90f6577 commit 07094641f2cee3834565790af93404d0741c1154
Showing 4,646 changed files with 564,933 additions and 0 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
@@ -0,0 +1,7 @@
// files that end in .txt list other tests
// other lines are assumed to be .html files

--min-version 2.0.0 conformance2/00_test_list.txt
@@ -0,0 +1,127 @@
Rules for Claiming a Conformant WebGL Implementation

The WebGL API is a web standard, and many web browser implementers
deliver their browser on multiple operating systems (OSs). WebGL
implementations also typically rely on the presence of an OpenGL or
OpenGL ES implementation on the OS. It can be appreciated that a WebGL
implementation therefore has many dependencies. This document attempts
to clarify to potential implementers the rules the Khronos Group uses
to judge whether a particular WebGL implementation is conformant.

There are two primary reasons to submit conformance results:

A) A web browser implementer desires to certify their WebGL
implementation as conformant.

B) A GPU manufacturer delivering an embedded system including web
browser with WebGL support desires to certify their WebGL
implementation as conformant.

Each of these situations carries different constraints, so the
conformance rules are phrased differently for each. Typically, a web
browser implementer aims to certify that the WebGL "layer" is correct.
A GPU vendor typically aims to certify that a given device is
physically capable of passing the tests.

A newly-developed WebGL implementation should not support the "webgl"
HTML Canvas context type by default in a shipping version of the
product until reaching conformance. It is acceptable to give end users
an option to turn on WebGL support in a non-conformant implementation
as long as the documentation for that option clearly indicates that
the implementation is not yet conformant and may have compatibility
issues. It is suggested that the Canvas context type
"experimental-webgl" may be supported by default in such

A WebGL implementation might reach conformance, but a subsequent
graphics driver release on a particular OS might introduce a
regression causing failures of one or more of the WebGL conformance
tests. In this situation it is not required to revoke support for the
"webgl" HTML Canvas context type. The WebGL implementer should work
with the GPU vendor to ensure the driver regression is fixed. A
situation like this would, however, prevent the WebGL implementer from
conforming to a subsequent version of the test suite.

(A) Conformance Rules for a Web Browser Implementer

1. Conformance on a particular operating system

On a given OS, a WebGL implementation will be considered to conform to
a particular version of the conformance suite if the suite passes with
no test failures on at least two GPUs, each from a different
vendor. If the OS only supports a GPU from one vendor, the two-GPU
requirement is dropped.

2. Conformance across multiple operating systems

A WebGL implementation will be considered to conform to a particular
version of the conformance suite if it passes rule (1) on all of the
OSs on which the WebGL implementation is intended to be supported.

3. Conformance as the web browser is upgraded

WebGL conformance results submitted for an earlier version of the
browser carry forward to later versions of the browser that do not
cause any previously passing test to fail.

4. Conformance as the operating system is upgraded

If a new version is released of one of the OSs on which a WebGL
implementation is intended to run, then WebGL conformance results
submitted for earlier versions of that OS carry forward. Future
conformance results must be submitted against the new version of the
OS. If it is anticipated that the older OS version will be supported
for some time, then future conformance results must be submitted
separately for both the old and new versions of the OS.

(B) Conformance Rules for a GPU Vendor

A GPU vendor submitting conformance results for a WebGL implementation
typically does so because the device containing the GPU includes a
built-in web browser. In this case the following rules apply:

1. Conformance results must be submitted for each GPU and operating
system combination to be certified. It is not required to submit
results for different devices containing the same GPU and running the
same operating system that do not cause any previously passing test to

2. Conformance results carry forward for a given GPU as the operating
system and graphics driver are upgraded but do not cause any previously
passing test to fail.


A WebGL implementation intended to ship on three OSs may reach
conformance on two of them, but due to graphics driver bugs, may be
unable to reach conformance on the third. In this situation the
implementation is not yet considered to be conformant.

An existing WebGL implementation which conformed to an earlier version
of the test suite is not required to remove support for the "webgl"
HTML Canvas context type while in the process of conforming to a later
version of the test suite. However, the implementer must not advertise
conformance to the later version until it has been reached. It is
acceptable for the implementer to advertise details of their
conformance, for example number or percentage of passing or failing
tests, or names of passing or failing tests.

A GPU vendor might submit conformance results in order to use the
WebGL logo in a marketing campaign. In this situation, results may be
submitted in advance of the product becoming available through sales
channels, per the rules above.

The WebGL API has strict security requirements. Even one failing test
may indicate a serious security issue in the WebGL implementation. For
this reason, no exceptions for failing conformance tests will be

The Khronos Group determines whether a particular WebGL implementation
is conformant based on the implementer's conformance suite
submissions, on multiple OSs and on multiple GPUs as necessary, using
the rules above. An implementer shall not judge their own
implementation conformant simply by applying the above rules.
@@ -0,0 +1,79 @@
Welcome to the WebGL Conformance Test Suite

Note: Before adding a new test or editing an existing test
[please read these guidelines](

This is the WebGL conformance test suite. You can find a the current "live"
version at [](

NOTE TO USERS: Unless you are a WebGL implementor, there is no need to submit
a conformance result using this process. Should you discover bugs in your
browser's WebGL implementation, either via this test suite or otherwise,
please report them through your browser vendor's bug tracking system.

FOR WEBGL IMPLEMENTORS: Please follow the instructions below to create
a formal conformance submission.

1. Open webgl-conformance-tests.html in your target browser

2. Press the "run tests" button

3. At the end of the run, press "display text summary"

4. Verify that the User Agent and WebGL renderer strings identify your browser and target correctly.

5. Copy the contents of the text summary (starting with "WebGL Conformance Test Results") and send via email to

Please see CONFORMANCE_RULES.txt in this directory for guidelines
about what constitutes a conformant WebGL implementation.

Usage Notes:

There are various URL options you can pass in.

run: Set to 1 to start the tests automatically

Example: webgl-conformance-tests.html?run=1

version: Set to the version of the harness you wish to run. Tests
at this version or below will be run

Example: webgl-conformance-tests.html?version=1.3.2

minVersion: Set to the minimum version of each test to include. Only tests
at this version or above will be included.

Example: webgl-conformance-tests.html?minVersion=1.3.2

fast: Only run tests not marked with --slow

Example: webgl-conformance-tests.html?fast=true

skip: Comma separated list of regular expressions of which tests to skip.

Example: webgl-conformance-tests.html?skip=glsl,.*destruction\.html

include: Comma separated list of regular expressions of which tests to include.

Example: webgl-conformance-tests.html?include=glsl,.*destruction\.html

frames: The number of iframes to use to run tests in parallel.

Example: webgl-conformance-tests.html?frames=8

Note the tests are not required to run with anything other than frames = 1.


The dates below are when work on the conformance suite version was started.

- 2011/02/24: Version 1.0.0
- 2012/02/23: Version 1.0.1
- 2012/03/20: Version 1.0.2
- 2013/02/14: Version 1.0.3
- 2013/10/11: Version 2.0.0 (beta)
- 2014/11/14: Version 1.0.4
@@ -0,0 +1,19 @@
# This is a list of contributors to the Closure Library.

# Names should be added to this file like so:
# Name or Organization <email address>

Google Inc.
Stellar Science Ltd.
Mohamed Mansour <>
Bjorn Tipling <>
SameGoal LLC <>
Guido Tapia <>
Andrew Mattie <>
Ilia Mirkin <>
Ivan Kozik <>
Rich Dougherty <>
Chad Killingsworth <>
Dan Pupius <>
Mike Dunn <>
Kengo Toda <>
@@ -0,0 +1,48 @@
Closure Library welcomes patches/pulls for features and bugfixes.

For contributors inside Google, follow the instructions given here:

For contributors external to Google, follow the instructions given here:

Notes on Contributions to Closure Library

Google Individual Contributor License

In all cases, contributors must sign a contributor license agreement,
either for an individual or corporation, before a patch can be
accepted. Please fill out the agreement for an individual or a
corporation, as appropriate.

If you or your organization is not listed there already, you should
add an entry to the AUTHORS file as part of your patch.

If you plan to add a significant component or large chunk of code, it
is recommended to bring it up on the discussion list for a design
discussion before writing code.

If appropriate, write a unit test that demonstrates your patch. Tests are the
best way to ensure that future contributors do not break your code

To change the Closure Library source, you must submit a pull request
in GitHub. See the GitHub documentation here:

Closure Library developers monitor outstanding pull requests. They may
request changes on the pull request before accepting. They will also
verify that the CLA has been signed.

Oftentimes, the pull request will not be directly merged, but patched to
the internal Google codebase to verify that unit and integration tests
will Closure pass before submitting (and optionally make changes to
the patch to match style, fix text, or to make the code or comments
clearer). In this case, the issue associated with the pull request
will be closed when the patch pushed to the repository via the MOE
(Make Open Easy) system.

0 comments on commit 0709464

Please sign in to comment.
You can’t perform that action at this time.