RESOLVED FIXED 208331
maps.google.com is not loading properly, screen flickers when zooming 
https://bugs.webkit.org/show_bug.cgi?id=208331
Summary maps.google.com is not loading properly, screen flickers when zooming
Dean Jackson
Reported 2020-02-27 11:21:18 PST
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.
Attachments
Patch (2.42 KB, patch)
2020-02-28 15:02 PST, Dean Jackson 		no flags
DetailsFormatted DiffDiff
Patch (4.39 KB, patch)
2020-02-29 13:39 PST, Dean Jackson 		graouts: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2020-02-27 11:21:32 PST
<rdar://problem/59854734>
Dean Jackson
Comment 2 2020-02-27 11:21:46 PST
I'll upload a video showing the issue.
Radar WebKit Bug Importer
Comment 3 2020-02-27 11:21:56 PST
<rdar://problem/59854754>
Dean Jackson
Comment 4 2020-02-27 11:22:41 PST
Real radar is <rdar://problem/59790757>
Radar WebKit Bug Importer
Comment 5 2020-02-27 11:22:55 PST
<rdar://problem/59854810>
Alexey Proskuryakov
Comment 6 2020-02-27 15:24:16 PST
That's what happens when you click through the Bugzilla warning and remove the keyword! <rdar://problem/59790757>
Kenneth Russell
Comment 7 2020-02-27 15:43:53 PST
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.
Kenneth Russell
Comment 8 2020-02-27 15:44:31 PST
Seems to have regressed during the ANGLE switch in bug 205483.
Dean Jackson
Comment 9 2020-02-28 11:11:12 PST
https://www.google.com/maps/@-33.8482439,150.9319747,10z:5170:242: CONSOLE ERROR WebGL: INVALID_FRAMEBUFFER_OPERATION: drawArrays: framebuffer not complete
Dean Jackson
Comment 10 2020-02-28 11:11:51 PST
(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.
James Darpinian
Comment 11 2020-02-28 12:28:12 PST
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?
Dean Jackson
Comment 12 2020-02-28 12:48:51 PST
(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?
Dean Jackson
Comment 13 2020-02-28 12:56:03 PST
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
Dean Jackson
Comment 14 2020-02-28 14:11:48 PST
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.
Kenneth Russell
Comment 15 2020-02-28 14:51:47 PST
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.
Dean Jackson
Comment 16 2020-02-28 15:02:45 PST
Created attachment 392023 [details] Patch
Dean Jackson
Comment 17 2020-02-28 15:04:14 PST
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.
Kenneth Russell
Comment 18 2020-02-28 15:17:47 PST
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.
Dean Jackson
Comment 19 2020-02-28 17:13:10 PST
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.
Dean Jackson
Comment 20 2020-02-29 13:35:49 PST
Test is webgl/1.0.3/conformance/renderbuffers/framebuffer-object-attachment.html
Dean Jackson
Comment 21 2020-02-29 13:39:51 PST
Created attachment 392071 [details] Patch
Antoine Quint
Comment 22 2020-02-29 14:12:31 PST
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.
Kenneth Russell
Comment 23 2020-03-01 10:52:47 PST
LGTM to me too.
Dean Jackson
Comment 24 2020-03-02 09:37:47 PST
Committed r257716: <https://trac.webkit.org/changeset/257716>
Kenneth Russell
Comment 25 2020-03-02 15:21:51 PST
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
Note You need to log in before you can comment on or make changes to this bug.