We haven‘t posted an update on the development status of ANGLE in quite some time and we’d like to provide an update on some of the new features and improvements that we've been working on.
As announced in the [Chromium Blog] (http://blog.chromium.org/2011/11/opengl-es-20-certification-for-angle.html), ANGLE v1.0 has passed the Khronos OpenGL ES 2.0 certification process and is now a conformant OpenGL ES 2.0 implementation.
We have recently completed the implementation of depth texture support ([ANGLE_depth_texture] (https://code.google.com/p/angleproject/source/browse/extensions/ANGLE_depth_texture.txt?name=master)) and earlier in the year we added support for instancing via attribute array divisors ([ANGLE_instanced_arrays] (https://code.google.com/p/angleproject/source/browse/extensions/ANGLE_instanced_arrays.txt?name=master)). See ExtensionSupport for a complete list of extensions that are supported by ANGLE.
We have also made a number of improvements in the shader compiler.
These fixes result in ANGLE being able successfully compile a number of the more complex shaders. Unfortunately there are still some complex shaders which we have not yet been able to obtain solutions for. Ultimately Direct3D 9 SM3 shaders are more restricted than what can be expressed in GLSL. Most of the problematic shaders we've encountered will also not compile successfully on current ES 2.0 implementations. We would only be able to achieve parity with Desktop GL implementations by using Direct3D 10 or above.
We have also made a major change to ANGLE in the way the origin difference between D3D and OpenGL is handled. This difference is normally observable when using render-to-texture techniques, and if not accounted for, it would appear that images rendered to textures are upside down. In recent versions of ANGLE (r536 (on Google Code)-r1161 (on Google Code)), we have been storing surfaces following the D3D Y convention where (0, 0) is the top-left, rather than GL's bottom-left convention. This was done by vertically flipping textures on load and then adjusting the texture coordinates in the shaders to compensate. This approach worked well, but it did leave the orientation of pbuffers inverted when compared to native GL implementations. As of ANGLE r1162 (on Google Code), we have changed this back to the original way it was implemented - textures are loaded and stored in the GL orientation, and the final rendered scene is flipped when it is displayed to a window by eglSwapBuffers. This should be essentially transparent to applications except that orientation of pbuffers will change. In addition to fixing the pbuffer orientation, this change:
Finally, Alok P. from Google has been working on implementing a new shader preprocessor for the last number of months and this effort is nearly complete. This new preprocessor should be more robust and much more maintainable. It also includes many (~5000) unit tests and passes all WebGL conformance tests. If you wish to try this out before it is enabled by default, define ANGLE_USE_NEW_PREPROCESSOR=1 in your project settings for the translator_common project.
As always we welcome contributions either in the bug reports (preferably with an isolated test-case) or in the form of code contributions. We have added a ContributingCode wiki page documenting the preferred process for contributing code. We do need to ask that you sign a Contributor License Agreement before we can integrate your patches.