Bug 208331

<rdar://problem/59854734>

I'll upload a video showing the issue.

<rdar://problem/59854754>

Real radar is <rdar://problem/59790757>

<rdar://problem/59854810>

That's what happens when you click through the Bugzilla warning and remove the keyword!

<rdar://problem/59790757>

I don't seem to be able to reproduce this in the iOS Simulator. Built via:

./Tools/Scripts/build-webkit --ios-simulator --release

and ran via:

./Tools/Scripts/build-webkit --ios-simulator --release

Enabled the hardware "iPad Pro (9.7-inch)" running iOS 13.3.

maps.google.com renders correctly. I can't tell whether it's using WebGL or its Canvas 2D based backend. Satellite view works, but it doesn't seem to be the Globe view that would clearly indicate WebGL is in use.

Seems to have regressed during the ANGLE switch in bug 205483.

https://www.google.com/maps/@-33.8482439,150.9319747,10z:5170:242: CONSOLE ERROR WebGL: INVALID_FRAMEBUFFER_OPERATION: drawArrays: framebuffer not complete

(In reply to Alexey Proskuryakov from comment #6)
> That's what happens when you click through the Bugzilla warning and remove
> the keyword!
> 
> <rdar://problem/59790757>

Aha! Thanks for telling me. I've been wondering why that is.

I can reproduce in the iOS simulator, but I have to add ?force=webgl to the end of the URL. It doesn't use webgl by default. I wonder how people are getting webgl by default?

(In reply to James Darpinian from comment #11)
> I can reproduce in the iOS simulator, but I have to add ?force=webgl to the
> end of the URL. It doesn't use webgl by default. I wonder how people are
> getting webgl by default?

iPad or iPhone?

Problem seems to be:

WebGL createFramebuffer
ANGLE GenFramebuffers -> 2
WebGL bindFramebuffer 2

WebGL createRenderbuffer
ANGLE GenRenderbuffers -> 2
ANGLE FramebufferRenderbuffer (GL_FRAMEBUFFER DEPTH_STENCIL_ATTACHMENT GL_RENDERBUFFER 2)

WebGL createTexture
ANGLE GenTextures -> 24

ANGLE FramebufferTexture2D (GL_FRAMEBUFFER COLOR_ATTACHMENT0 TEXTURE_2D 24)

Framebuffer is incomplete

Found the problem. We try to check if GL_ANGLE_depth_texture is enabled, but we don't need to do that any more with ANGLE.

Great work Dean tracking this down! Relieved it wasn't a deeper problem in ANGLE or the graphics driver.

Do you have a code snippet that shows exactly the setup of the incomplete framebuffer? I'd like to ensure that a WebGL conformance test is in place covering this.

Created attachment 392023 [details]
Patch

I think there is a conformance test that covers this. Probably one of the ones I skipped in 207858 for iOS.

I'm compiling for all platforms now to double check this, but maybe EWS will tell me sooner.

Comment on attachment 392023 [details]
Patch

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

> Source/WebCore/ChangeLog:10
> +        We were mistakenly checking for it and deciding to not all

all -> allow

> Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:806
> +        m_isGLES2NPOTStrict = false;

Are we sure this is the correct setting? ANGLE advertises GL_OES_texture_npot as an enableable extension, meaning that it should be disabled by default for WebGL compatible contexts.
https://source.chromium.org/chromium/chromium/src/+/master:third_party/angle/src/libANGLE/Caps.cpp;l=900?q=OES_texture_npot%20f:third_party%2Fangle
https://source.chromium.org/chromium/chromium/src/+/master:third_party/angle/src/tests/gl_tests/WebGLCompatibilityTest.cpp;l=2133?q=OES_texture_npot%20f:third_party%2Fangle

I think this could be set to true which would speed up validation of draw calls.

Comment on attachment 392023 [details]
Patch

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

Also, given that no tests changed on iOS, I don't think this is covered in the conformance suite.

>> Source/WebCore/ChangeLog:10
>> +        We were mistakenly checking for it and deciding to not all
> 
> all -> allow

Fixed.

>> Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:806
>> +        m_isGLES2NPOTStrict = false;
> 
> Are we sure this is the correct setting? ANGLE advertises GL_OES_texture_npot as an enableable extension, meaning that it should be disabled by default for WebGL compatible contexts.
> https://source.chromium.org/chromium/chromium/src/+/master:third_party/angle/src/libANGLE/Caps.cpp;l=900?q=OES_texture_npot%20f:third_party%2Fangle
> https://source.chromium.org/chromium/chromium/src/+/master:third_party/angle/src/tests/gl_tests/WebGLCompatibilityTest.cpp;l=2133?q=OES_texture_npot%20f:third_party%2Fangle
> 
> I think this could be set to true which would speed up validation of draw calls.

You're correct.

Test is webgl/1.0.3/conformance/renderbuffers/framebuffer-object-attachment.html

Created attachment 392071 [details]
Patch

Comment on attachment 392071 [details]
Patch

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

> Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:799
> +    // turning it off causes problems.

Please file a bug to track working this out.

LGTM to me too.

Committed r257716: <https://trac.webkit.org/changeset/257716>

A follow-on bug has been filed in the ANGLE issue tracker for exposing GL_ANGLE_depth_texture even when the GL_OES_depth32 extension isn't supported:

https://bugs.chromium.org/p/angleproject/issues/detail?id=4451