924411 - panning in Google Maps slower than in Chrome

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Arpad Borsos [:Swatinem]]

We have discussed this a little at the summit, I have a few examples of google maps uses which are a lot slower in FF than in Chrome.

STR:
1. load http://www.redbullxalps.com/live-tracking.html
2. on the left click on weather
3. select "Wind m/s" from the dropdown that appears on the lower left
4. pan around with the mouse

Due to the gmaps api, each element is `position: absolute` with top/left, and everyone is updated on pan.
Paint-flashing reveals that actually the whole row is repainted, also between the individual arrows. So it might be a reflow issue (you mentioned some issues with `right: auto`?)


Another example:

http://www.flightradar24.com/50.01,14.67/6

They actually use canvases the size of map tiles to get a really great performance compared to the number of icons visible. Still, performance is a lot worse than in chrome, where panning is a lot smoother (apart from the occasional hangs when the data is refreshed)

Comment 1

[Daniel Holbert [:dholbert]]

> (you mentioned some issues with `right: auto`?)
(I actually had that a bit backwards - a problem-case where we'd definitely need reflows would be with right *non-auto*, e.g. "position:absolute; left: 10px; right: 10px; width: auto". If you make dynamic changes to "left", while holding "right" constant, then this ends up reducing our actual width, which needs a reflow.)

(From skimming the code, though, it looks like we're at least a bit smart about this -- we won't reflow if "width" is a fixed value, which it probably is here, since these are fixed-size tiles. So depending on how much is updated on each pan, we probably aren't actually triggering reflows.)

We are likely triggering lots of repaints, at least. I'll bet we don't allocate layers for these absolutely-positioned tiles (whereas we do for css-transformed content) so when they move, we have to repaint them, which means repainting the whole screen. (which is what I see, from paint flashing)

Comment 2

[Daniel Holbert [:dholbert]]

Here's a profile of panning around, after performing the STR (with 4 consecutive "click and drag" operations, visible as the ~4 peaks):
 http://people.mozilla.org/~bgirard/cleopatra/#report=44234d7086a9f2031709f23ebedcb77ed07d77d6

If I select the first peak and drill down, it looks like we're spending ~56% of our time running script, and another ~20% in PresShell::Paint (inside of Timer::Fire > nsRefreshDriver::Tick).

Comment 3

[Daniel Holbert [:dholbert]]

[broadening OS to "all", as I can see the perf difference on Linux]

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Arpad Borsos (Swatinem) from comment #0)
> Due to the gmaps api, each element is `position: absolute` with top/left,
> and everyone is updated on pan.

mattwoodrow says roc is working on something that might improve our perf under this sort of use-case.  CC'ing roc

Comment 5

[Daniel Holbert [:dholbert]]

Yeah, looks like bug 876321 would hopefully reduce the need for repaints here.  Marking dependency.

Comment 6

[Arpad Borsos [:Swatinem]]

With bug 876321 being fixed on nightly, this is still a big pain and unusably slow, at least on linux (havent tested on windows yet, but drawing is A LOT faster there in general).

According to paint flashing, layerization seems to work for the redbull demo. When I pan around, both the background tiles and the overlay arrows have the same color and keep that during pans, only the newly visible regions are repainted.

For the flightradar demo, the tiles get repainted every time. They change colors all the time on panning, and all the tiles have different colors, so I suspect they are not put into one layer together?

Comment 7

[jfeng1985]

So, interesting note, I've found that I get very poor performance panning when using an external mouse, but actually get decent panning performance when using my laptop's track pad.  The difference between the two is the rate at which mouse motion events are generated - about 500Hz for the mouse, and 80Hz for the track pad.  I did a little further digging and it looks like Google Maps doesn't appear to use requestAnimationFrame anywhere, so that seems to fit my theory that the poor performance is at least partially due to too many re-drawing attempts.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

This is good info, thanks.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Probably related to bug 837985.

Comment 10

[Gregory Pappas [:gregp]]

There are still known performance issues with Google Maps that have been filed elsewhere. Firefox and Google Maps have both changed a lot in the last ten years and most of this analysis is too outdated to be useful. Comment 7 is intriguing though, so I'm going to link this to the current bug.