1719083 - Switching from satellite view to Street View on Google Maps takes time the first time

Status: RESOLVED WORKSFORME

(Core :: Performance, defect)

Description

[Alice0775 White]

Switching from satellite view to Street View on Google Maps takes time the first time.
I think Google changed their web site(JavaScript code or something?) by themselves.

Reproducible: yes, first time

Steps to reproduce:

1. Clear recent history everything if any
2. Open Google maps e.g,https://www.google.co.jp/maps/@34.7155252,135.5896482,17z?hl=ja
3. Click on the image button at the bottom left to switch to Satellite view.
4. Drag and drop the orange human figure onto the blue line on the map to switch to Street View.

Actual results:
It takes time(about 10-20 seconds) to switch from satellite view to street view.
Profiler log:
first time(Drop the orange human at 4.7s. the switching takes more then 20sec)
https://share.firefox.dev/3qLPkXL
2nd time(Drop the orange human at 3.2s. the switching takes only 3sec)
https://share.firefox.dev/3jGPyOr

Expected results:
It shouldn't take more than a few seconds and will switch instantly.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=45808ab18609bfd3b69c6ae2d21e2b50f5177a02&tochange=6188f34970576cf032692bc8679eca89607dfe34

Suspect: Bug 1501794

Comment 1

[Alice0775 White]

Attachment: about:support

Comment 2

[Sean Feng [:sefeng]]

Looks like the network request which starts with https://www.google.co.jp/maps/rpc/vp?authuser=0&hl=ja&gl=jp& is responsible for loading the satellite view. And it's triggered by an XHR request in an rAF callback.

The difference in profiles is that the content process was being idle for like 12 seconds in the slow profile, and I don't see a such long wait like this in the fast profile.

What do you think Olli?

Comment 3

[Alice0775 White]

I have confirmed that others can also reproduce this problem.
see http://forums.mozillazine.org/viewtopic.php?f=23&t=3076449&p=14897453

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Somehow the main thread is idle until it processes a PostMessageRunnable.
That is for a MessagePort.
Do we have a busy Worker somewhere... or I guess MessageChannel could be used also just in the main thread.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Hmm, PostMessageRunnable wasn't delayed much.

Comment 6

[Alice0775 White]

I am not sure this is related or not.

Console shows a lot of WebGL warning:

00:15:55.034 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:15:55.034 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:15:56.531 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:15:56.531 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:15:59.009 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:15:59.010 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:15:59.010 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:15:59.010 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:15:59.010 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:15:59.010 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:15:59.010 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:15:59.010 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:16:03.380 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:16:03.380 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:16:06.749 WebGL warning: copyTexSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:16:06.749 WebGL warning: copyTexSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
00:16:07.696 WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow.
00:16:07.696 WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Somehow dropping the human figure takes lots of time. Child process gets the mouseup event and some JS runs but the human figure changes it style to 'dropped' several seconds later. And once it happens the page enters Street View.

Comment 9

[Alice0775 White]

From regression window of commwnt #0, I think the suspected bug is Bug 1540189 or Bug 1501794.

Comment 10

[Jorge]

Not sure if this helps, but I've just seen this happen in the latest official Chrome in "incognito mode".
It only hangs the first time the little yellow/orange man is dragged and dropped, on the following tries there is no delay.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

That may help. I'll send this information to Google.
And yes, I can reproduce it too. One needs to clear browsing data first.

Comment 13

[Alice0775 White]

No longer reproduce the issue on 90.0.2,91.0b5 and 92.0a1 as well as 89.0.2.