| Summary: | First search on Google Maps shows black bar at top of map and blank strips through the middle | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Dean Jackson <dino> | ||||||||||||
| Component: | WebGL | Assignee: | Dean Jackson <dino> | ||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||
| Severity: | Normal | CC: | darin, dino, jdarpinian, jonahr, kbr, mmaxfield, thorton, webkit-bug-importer | ||||||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||||||
| Version: | WebKit Nightly Build | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Bug Depends on: | 208331, 210992, 214897 | ||||||||||||||
| Bug Blocks: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Dean Jackson
2020-07-29 15:38:00 PDT
Created attachment 405517 [details]
Screenshot
Could this be related to earlier Google Maps-related bugs with the ANGLE backend, Bug 208331 and Bug 210992? A significant ANGLE roll was just done in Bug 214897 - possible to re-test on top of that? Looking at the screenshot it appears something went wrong with tile clipping. In Google Maps tiles can be clipped using either the stencil buffer or the scissor rect. If I had to guess I would say that it is probably using the stencil buffer in this case. Each tile is assigned a unique stencil value and the stencil buffer is filled with these values in a pass that happens first, before other things are drawn. It looks to me as though there is an erroneous vertical offset being applied during the stencil pass, and then subsequent drawing of roads is being clipped incorrectly by the incorrect stencil buffer. Updating bugzilla. This is not a regression in iOS 14, and likely not related to WebGL. I'll attach a screen recording and two frames as static images. It appears that what is happening is Google Maps selects a (destination?) viewport when the keyboard accessory bar is visible, animates to the searched location, and doesn't realise that the accessory bar is now hidden (and thus the viewport has changed). Or, more specifically, one part of the app doesn't notice this, since you can see in the two frames (which are adjacent in the timeline) that it does decide to squish its zoom ratio in the horizontal axis. Created attachment 406336 [details]
screen recording
Created attachment 406337 [details]
Frame A
Created attachment 406338 [details]
Frame A+1
Notice that the horizontal viewing area changes between A and A+1 but the vertical does not. (Also funny that two PNGs taken from the video end up larger than the video itself) Created attachment 406486 [details]
Patch
Committed r265581: <https://trac.webkit.org/changeset/265581> Comment on attachment 406486 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406486&action=review > Source/WebCore/ChangeLog:19 > + Rather than have Google Maps update its code to detect these viewport changes, > + we're adding a Quirk to not use the control bar in these calculations. This sounds like it’s our forever solution. Do you mean, "Until Google Maps updates its code"? (In reply to Darin Adler from comment #12) > Comment on attachment 406486 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=406486&action=review > > > Source/WebCore/ChangeLog:19 > > + Rather than have Google Maps update its code to detect these viewport changes, > > + we're adding a Quirk to not use the control bar in these calculations. > > This sounds like it’s our forever solution. Do you mean, "Until Google Maps > updates its code"? Yes, that's what I meant. Google Maps could fix this on their end, but this solves it for now. I'll email contacts there to encourage them, but they'll now have to use iOS 13 to test a fix. |