maps.google.com is not loading properly, screen flickers when zooming Steps To Reproduce: 1. Open Safari 2. Go to maps.google.com 3. Page will not load properly, only text will be visible 4. Zooming in and out causes the screen to flicker briefly revealing the map before turning black again Results: Expected: I should be able to use maps.google.com and clearly see the map. Actual: The only thing visible on maps.google.com is the text, zooming in and out temporarily reveals the map. This only reproduces on iOS using an iPad. I have not tried using the iOS simulator yet.
<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