1529514 - [ARM64] Bing maps is slowing down the browser and remains stuck when zooming out using touchscreen

Status: NEW

(Core :: JavaScript Engine, defect, P2)

Description

[David Olah]

[Affected versions]:
Beta 66.0b10, Nightly 67.0a1

[Affected platforms]:
Platforms: Windows [Lenovo Yoga]

[Steps to reproduce]:

1. Open Firefox and go to https://www.bing.com/maps/
2. Use your fingers to zoom in the map to maximum size (directly on the touchscreen display)
3. The same way, zoom out quickly to minimum size

Expected Result:
Maps are zoomed out.

Actual Results:
The maps crash visually and a Yellow message is shown on top of the page: "A web page is slowing down your browser. What would you like to do?" [Check attachment]

Comment 1

[David Olah]

Attachment: 7Qk9jtw.png

Comment 2

[Andrew Overholt [:overholt]]

The slow script doorhanger indicates this might be a JS issue. But it could also be a DOM: Events bug. Let's start with JS.

Comment 3

[Nicolas B. Pierron [:nbp]]

We should capture a profile to double check that this is a JavaScript bug, but I can even reproduce this issue after enabling IonMonkey.

Comment 4

[Nicolas B. Pierron [:nbp]]

Here is a profile, which I captured after using 2 fingers (from both hands) and moving them around in a random fashion without taking my fingers out of the screen. Edge does not lag in any way when doing the same action.

The slow-script message still does not appear, but the web site feels unresponsive with up to 1s of event processing delay.

In this profile, we notice:

• 50% in CanvasRenderingContext2D.scale (incl. 49% in Skia's neon::memset32)
• 16% in set HTMLCanvasElement.width
• 14% in js::ConcatStrings (incl. 12% in js::GCRuntime::collect)

Andrew, do you know who might be the best person to investigate these DOM / Skia issues?

Comment 5

[Jon Coppeard (:jonco)]

The profile shows a lot of GCs for TOO_MUCH_MALLOC although the GC heap size doesn't change much after collection. We may be triggering too many GCs here due to a scheduling issue.

On desktop I see 22% time in memset32 and the same pattern of GCs.

Comment 6

[Jon Coppeard (:jonco)]

(In reply to Jon Coppeard (:jonco) from comment #5)
For the GC issue, the patch I posted in bug 1395509 comment 8 addresses this in local testing. My guess at what's happening is we're creating and destroying tons of canvas nodes. The original memory accounting scheme doesn't see the destruction and just sees lots of allocation, so triggers GCs. With the patch this doesn't happen.

Comment 7

[Andrew Overholt [:overholt]]

(In reply to Nicolas B. Pierron [:nbp] from comment #4)

Here is a profile, which I captured after using 2 fingers (from both hands) and moving them around in a random fashion without taking my fingers out of the screen. Edge does not lag in any way when doing the same action.

The slow-script message still does not appear, but the web site feels unresponsive with up to 1s of event processing delay.

In this profile, we notice:

• 50% in CanvasRenderingContext2D.scale (incl. 49% in Skia's neon::memset32)
• 16% in set HTMLCanvasElement.width
• 14% in js::ConcatStrings (incl. 12% in js::GCRuntime::collect)

Andrew, do you know who might be the best person to investigate these DOM / Skia issues?

I think Jessie might have thoughts.

Comment 8

[Jessie [:jbonisteel] pls NI]

Lee, can you take a peak next week?

Comment 9

[Lee Salzman [:lsalzman]]

Is this profile from a Qualcomm device? In bug 1515823 we disabled D2D due to stability and correctness issues. That would mean Canvas2D falls back to Skia instead of using D2D, which would be bound by the software performance of clearing the canvas on each frame.

In general, we are trying to encourage complex performance-sensitive rendering cases to migrate to WebGL instead of relying on Canvas2D (i.e. Google maps and such) to work around these issues.

I can try to investigate if there is anything extra we can do to elide some of these clears. I am not sure it will turn up much, as we already optimized the low hanging fruit there about as much as we could.

Comment 10

[Kelsey Gilbert [:jgilbert]]

Setting HTMLCanvasElement.width incurs a clear, but maybe we can make that lazy?

Like lsalzman says, there's not a ton we can do for scale, probably. Maybe it's worth checking we're not hitting a particularly slow slow-path, but I expect that to be a performance long-pole on these CPU-canvas+low-bandwidth-ARM systems.

Comment 11

[Kelsey Gilbert [:jgilbert]]

Oh geez, they're recreating a new canvas2d each resize and rescaling it during newCanvas.drawImage(oldCanvas), aren't they?

Comment 12

[Kelsey Gilbert [:jgilbert]]

If they're doing this so they don't have to wait around for new data, I wonder if we can have them lean on the compositor's rescaling by holding on to the last-complete-canvas, and showing a scaled version of that in the foreground as they work on producing the next zoomed canvas in the background.

(This is alllll theories, but it seems possible!)

Comment 13

[Nicolas B. Pierron [:nbp]]

(In reply to Lee Salzman [:lsalzman] from comment #9)

Is this profile from a Qualcomm device?

Yes, it is.