Open Bug 1529514 Opened 6 months ago Updated 3 months ago

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

Categories

(Core :: JavaScript Engine, defect, P2)

ARM64
Windows 10
defect

Tracking

()

Tracking Status
firefox66 --- affected
firefox67 --- fix-optional

People

(Reporter: david.olah, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs, Regression)

Details

Attachments

(1 file)

[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]

Attached image 7Qk9jtw.png
Hardware: Unspecified → ARM64
Summary: Bing maps is slowing down the browser and remains stuck when zooming out using touchscreen → [ARM64] Bing maps is slowing down the browser and remains stuck when zooming out using touchscreen

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.

Component: Graphics → JavaScript Engine
Depends on: 1530688

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

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?

No longer blocks: arm64-windows-js-bugs
Flags: needinfo?(overholt)

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.

(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.

(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.

Flags: needinfo?(overholt) → needinfo?(jbonisteel)

Lee, can you take a peak next week?

Flags: needinfo?(jbonisteel) → needinfo?(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.

Flags: needinfo?(lsalzman) → needinfo?(nicolas.b.pierron)
Regressed by: 1515823

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.

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

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!)

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

Is this profile from a Qualcomm device?

Yes, it is.

Flags: needinfo?(nicolas.b.pierron)
You need to log in before you can comment on or make changes to this bug.