Bug 57261 – [Qt] Migrate to GraphicsContext3DOpenGL.cpp

• Component: WebGL
• Status: RESOLVED FIXED

[Jarkko Sakkinen]

Adapt to GraphicsContext3DOpenGL.cpp for handling GraphicsContext3D calls. GraphicsContext3DQt.cpp should be limited symbol resolving and context handling.

[Jarkko Sakkinen]

Created attachment 87259 [details]
Compilation of ANGLE shader compiler.

This is what it takes to get ANGLE shader compiler to compile. I guess there should be a separate .pro file for ANGLE?

[Jarkko Sakkinen]

Created attachment 87309 [details]
GraphicsContext3DOpenGL.cpp experimental patch

[Jarkko Sakkinen]

Note with experimental patch some of the layout tests start to fail. This is because those layout tests are invalid since their shaders do not apply to WebGL 1.0 standard.

[Jarkko Sakkinen]

Created attachment 87364 [details]
clean up and compilation fix

[Jarkko Sakkinen]

Created attachment 87483 [details]
clean up

[Jarkko Sakkinen]

Created attachment 87500 [details]
Adapted to symbol resolver changes.

[Jarkko Sakkinen]

Created attachment 87507 [details]
compilation fix

[Jarkko Sakkinen]

There are two questions to be answered before this patch can be finalized:

Problem 1.

GraphicsContext3DOpenGL.cpp excepts strict ES 2.0 shaders that always must have precisions defined. This also what the WebGL 1.0 standard states. This, however, cause most currently available WebGL pages to fail misserably because GC3DOGL validates pages with ANGLE. Most of the browsers support also these pages that do not apply to the standard. It is easy also to make our code to support that by appending default precisions to the shader code. Do we want to do this?


Problem 2.

See ANGLE import in WebCore.pro. I had to adjust compiler settings in order to get generated code to compile. Should this be in a separate binary blob with own pro file?

[Jarkko Sakkinen]

Shaders might have another issue that causes failure and this has to be fixed before making any conclusions on problem 1 and see how well SH_WEBGL (shader compiler mode in ANGLE, other is SH_ES2) GC3DOGL handles layout tests after that.

The problem is that with some pages ShConstructCompiler() called by ANGLEWebKitBridge::validateShaderSource() returns NULL. This is the reason that seems to cause part of layout tests fail.

[Andrew Wason]

(In reply to comment #9)
> The problem is that with some pages ShConstructCompiler() called by 
> ANGLEWebKitBridge::validateShaderSource() returns NULL.
> This is the reason that seems to cause part of layout tests fail.

This is because the builtin ANGLE resources are not being initialized on the ANGLEWebKitBridge - so they contain garbage which occasionally makes the builtin resources fail to parse. I'm working on updating the patch to fix that.

[Andrew Wason]

Created attachment 100040 [details]
fix ANGLE initialization

Fix ANGLE resource initialization so ShConstructCompiler() doesn't fail.
Adapt to TextureMapper changes. Adapt to ANGLE changes.
This patch should be applied on top of the patch from attachment 98541 [details] to bug 57154

Also, I think we should use Extensions3DOpenGL instead of Extensions3DQt, because Extensions3DQt is mostly stubs. I'll see if I can add that to this patch.

[Andrew Wason]

Created attachment 100997 [details]
implement antialiasing

Update for latest resolver patch on bug 57154.
Use Extensions3DOpenGL for desktop instead of Extensions3DQt.
Implement support for WebGL antialiasing.

[Andrew Wason]

I'm splitting this migration into 3 dependent parts.

Part 1, bug 64877, will move GraphicsContext3DInternal members into GraphicsContext3D where they will be needed when we adopt GraphicsContext3DOpenGL.cpp

Part 2, bug 64878, will adopt GraphicsContext3DOpenGL.cpp and ANGLE shader compiler.

Part 3, bug 64879, will implement WebGL antialiasing using GraphicsContext3DOpenGL.cpp and Extensions3DOpenGL.cpp

[Noam Rosenthal]

This was fixed in a series of other bugs.