Bug 42118 – Detect necessary OpenGL extensions and fail to create WebGL context if not present

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Sam Weinig]

Some of the WebGL tests don't pass if GL_ARB_framebuffer_object extension is not present. We should be falling back to the software renderer in this case.

[Sam Weinig]

Specifically, 



fast/canvas/webgl/context-attributes-alpha-depth-stencil-antialias.html	
fast/canvas/webgl/copy-tex-image-and-sub-image-2d.html	
fast/canvas/webgl/gl-uniformmatrix4fv.html	
fast/canvas/webgl/index-validation-with-resized-buffer.html	
fast/canvas/webgl/point-size.html	
fast/canvas/webgl/tex-image-and-sub-image-2d-with-array-buffer-view.html	
fast/canvas/webgl/tex-image-and-sub-image-2d-with-image-data.html	
fast/canvas/webgl/texture-active-bind.html	
fast/canvas/webgl/viewport-unchanged-upon-resize.html	

don't pass.

[Sam Weinig]

<rdar://problem/8183204>

[Kenneth Russell]

It isn't 100% clear that the lack of ARB_framebuffer_object is the most specific root cause. The Mac port assumes EXT_framebuffer_object and uses those entry points, which appear to be present on the machine in question. Sam provided a diff between the GL extensions on a machine where the tests work and on the machine where they're failing. Attaching this list separately. Note that EXT_framebuffer_object is present, though EXT_framebuffer_blit and EXT_framebuffer_multisample aren't, so antialiasing won't work -- but the WebGL implementation should notice that and simply disable antialiasing.

There might be a problem, seen on Macs with older ATI drivers, using non-power-of-two textures as color attachments to framebuffer objects. On these older machines it was necessary to use a GL_TEXTURE_RECTANGLE_ARB texture for the WebGL back buffer.

[Kenneth Russell]

Created attachment 61311 [details]
Diffs from Sam Weinig between available GL extensions on machine where tests are working vs. not working

[Chris Marrin]

Created attachment 61988 [details]
Patch to disable WebGL on Leopard

[Chris Marrin]

Created attachment 61990 [details]
replacement patch - forgot to disable in WebKit and JavaScriptCore projects

[Chris Marrin]

Leopard build disabled in http://trac.webkit.org/changeset/63688

[Csaba Osztrogonác]

r63688 broke 2 tests on Leopard bots:
compositing/webgl/webgl-background-color.html
compositing/webgl/webgl-reflection.html

http://build.webkit.org/results/Leopard%20Intel%20Release%20%28Tests%29/r63719%20%2817931%29/results.html

I think we should commit these expected fails for mac-leopard platform to make buildbots happy.

[Chris Marrin]

It appears that no driver for any Mac system before 10.6.3 supports this extension, not even the software renderer. Here is a nice chart that shows all the supported extensions:

    http://developer.apple.com/graphicsimaging/opengl/capabilities/index.html

So our only choice for now is to turn off WebGL when the extension is not present. That means not running on any system before 10.6.3 and falling back to the software renderer on some hardware after that.

[Kenneth Russell]

(In reply to comment #9)
> It appears that no driver for any Mac system before 10.6.3 supports this extension, not even the software renderer. Here is a nice chart that shows all the supported extensions:
> 
>     http://developer.apple.com/graphicsimaging/opengl/capabilities/index.html
> 
> So our only choice for now is to turn off WebGL when the extension is not present. That means not running on any system before 10.6.3 and falling back to the software renderer on some hardware after that.

This seems drastic. WebGL has been working fine for me on a Mac Pro running 10.5.8 with a GeForce GT 210. Problems are seen with the GeForce 7300 GT. I have gotten access to such a machine over the past couple of days and done some investigation into why WebGL fails to allocate its back buffer. One reason is that the color buffer needs to be a minimum of 16x16, apparently to meet alignment restrictions of this card's back buffer. However, after performing this rounding up, the depth buffer still fails to attach properly. The FBOBunnies sample from Apple's developer web site runs fine, however. I'm continuing to investigate the differences between WebGL's setup code and that from this sample.

[Chris Marrin]

Created attachment 62091 [details]
Disable compositing/webgl tests if WebGL not enabled

[Chris Marrin]

Created attachment 62092 [details]
Disable compositing/webgl tests if WebGL not enabled

[Chris Marrin]

Comment on attachment 62092 [details]
Disable compositing/webgl tests if WebGL not enabled

This patch replaces the previous one, which had some spurious diffs

[Eric Seidel (no email)]

Comment on attachment 61988 [details]
Patch to disable WebGL on Leopard

Cleared Darin Adler's review+ from obsolete attachment 61988 [details] so that this bug does not appear in http://webkit.org/pending-commit.

[Eric Seidel (no email)]

Comment on attachment 61990 [details]
replacement patch - forgot to disable in WebKit and JavaScriptCore projects

Cleared Darin Adler's review+ from obsolete attachment 61990 [details] so that this bug does not appear in http://webkit.org/pending-commit.

[Chris Marrin]

I was mistaken about support for framebuffer objects in Leopard. It's true that GL_ARB_framebuffer_object is not supported anywhere before 10.6.3, but the GL_EXT_framebuffer_object extension is supported in 10.5.8 on some hardware and the software renderer. So we can actually run on Leopard, but on some hardware it will be slow because of the software renderer. I am working on a patch that checks for this extension and disables WebGL if it's not present. That will make sure we fall back to the software renderer as needed and will make sure WebGL doesn't try to run on older OS's that don't have this extension.

[Zhenyao Mo]

(In reply to comment #16)
> I was mistaken about support for framebuffer objects in Leopard. It's true that GL_ARB_framebuffer_object is not supported anywhere before 10.6.3, but the GL_EXT_framebuffer_object extension is supported in 10.5.8 on some hardware and the software renderer. So we can actually run on Leopard, but on some hardware it will be slow because of the software renderer. I am working on a patch that checks for this extension and disables WebGL if it's not present. That will make sure we fall back to the software renderer as needed and will make sure WebGL doesn't try to run on older OS's that don't have this extension.

Can we roll out the original patch first?  My dev machine is a leopard, so now I have to unapply this patch for coding/testing, then apply this patch for code-review and commiting.  It's such a pain.

[Chris Marrin]

I've made this a more general bug of making sure we have all the necessary OpenGL extensions present. This will cause us to fallback to the software renderer if a driver does not have the functionality, or fail to create a WebGL context if even the software renderer does not have it.

[Adam Barth]

Comment on attachment 62092 [details]
Disable compositing/webgl tests if WebGL not enabled

Clearing simon.fraser's r+.  This patch appears to have landed.

[Brent Fulgham]

This code is already landed.