1612365 - Moving specific map is extremely slow to unusable

Status: RESOLVED FIXED

(Core :: Performance, defect, P1)

Description

[Ettore Atalan]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

1. Open the following URL in Firefox for Android (tested with Release 68.4.2) on a Touchscreen device:
   https://www.deutschepost.de/de/s/standorte.html

2. Move the map.

Actual results:

Even if you move the map quickly, it reacts very slowly or not at all.

Expected results:

The map should move according to the touch screen input.

Comment 1

[Laurentiu Apahidean]

I have managed to reproduce your issue on Firefox Release 68.4.2 and Beta 68.5b5 using a Pixel 3 XL (Android 9) and Samsung Galaxy S9 (Android 8.0.0), I will set this issue as new.
The issue also occurs on Firefox Preview Nightly, issue https://github.com/mozilla-mobile/fenix/issues/8018 has been submitted regarding this. The issue does not occur on Chrome.

Comment 2

[Markus Stange [:mstange]]

They draw the map using a 2d canvas during a touch event handler. Profile: https://perfht.ml/37qxpKN

We're bitten by two issues:

• We don't coalesce touchmove events.
• We use software rasterization for 2d canvas.

According to esmyth, this also reproduces on bing.com/maps.

Comment 3

[Markus Stange [:mstange]]

And a third issue:

• We don't repaint the screen frequently enough. There are 71 touchmove events with canvas paints, but only 10 Composites during the profiled time. This is because the DidComposite messages queue up behind the touchmove IPC messages, so the refresh driver doesn't tick. Bug 1506376 should help with this. https://perfht.ml/2Hopsex

filteredMarkers.filter(m => m.name == "DOMEvent" && m.data.eventType == "touchmove").length // with web content thread selected
filteredMarkers.filter(m => m.name == "Composite").length // with Renderer thread selected

Comment 4

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I marked this as a P3 because I don't think there is frontend work here.

Comment 5

[Markus Stange [:mstange]]

Let's move it out of the frontend component then. I'm moving it to Core :: Performance because it's more of a meta bug that is dependent on two bugs in two different components.

Comment 7

[Patricia Lawless]

Hi Laurentiu,
Both of the blocker bugs for this bug have been closed. Could you try to reproduce using Nightly? (Fx76)

Comment 8

[Markus Stange [:mstange]]

I just re-tested: It paints more frequently than in the original report, but touch move coalescing does not seem to be working. Touches queue up and the map keeps moving long after I've lifted my finger. Profile: https://perfht.ml/2x6bKuW
Maybe IPC message coalescing is being thwarted by the DynamicToolbarOffsetChanged messages that are now sent on touchmove?

Comment 9

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

Oh oh, interesting. That is some fenix specific. Since when I was testing touchmove compression I was using the example GV app, and
Windows builds on a touchscreen laptop.

IPC compression of course doesn't work if someone else is sending tons of unrelated IPC messages.
Only consecutive messages can be compressed.

Why are we sending so many DynamicToolbarOffsetChanged messages? And ChildToParentMatrix.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

I suppose in this case the dynamic toolbar shouldn't move, it's an issue in Fenix, the corresponding Gecko issue is bug 1618582.

:snorp, am I right about this case? I am supposing the touch moves which were consumed in the content should not affect dynamic toolbar movement, right?

Comment 11

[James Willcox (:snorp) ([e-mail]) (he/him)]

Right. There is a pr up to fix this in a-c here: https://github.com/mozilla-mobile/android-components/pull/6244/

Comment 12

[Laurentiu Apahidean]

(In reply to Patricia Lawless from comment #7)

Hi Laurentiu,
Both of the blocker bugs for this bug have been closed. Could you try to reproduce using Nightly? (Fx76)

Hello,
I have tested the issue on the latest Firefox Preview Nightly (Build# 20790606) GV: 76.0a1-20200317093640 using a OnePlus 6T (Android 9) and Huawei MediaPad M3 (Android 7.0). Panning and zooming is smoother, however as Markus pointed out these operations seem to queue resulting in the map moving without user input. This is more noticeable on older devices.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

For records/references, at that time when Markus tested the site, the dynamic toolbar on Fenix hadn't been implemented. Then the toolbar was implemented, but there was an issue which will be fixed by the PR what snorp mentioned hasn't merged yet.

CCing :liuche to make sure this is in their radar.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

The PR has been merged into android-components.

Laurentiu, would you mind re-testing the site?

Comment 15

[Laurentiu Apahidean]

I retested the issue on Firefox Preview Nightly 200327 (Build #208070608) GV: 76.0a1-20200325093457 3/27 using a OnePlus 6T (Android 9) and Huawei MediaPad M3 Lite 10 (Android 7.0). Panning and zooming operations are smooth and actions no longer stack up (the map no longer moves without user input).

Comment 16

[Patricia Lawless]

smaug: it looks like bugs this was dependent on have both been fixed (by you) - should this bug be closed as well?

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Yep, we can close this now.

(I couldn't put the PR link into "See Also", so I am putting the link into "URL" instead)