This is still very slow, but I'm not sure it's a gfx issue. Seeing a lot of JavaScript so I'll take it there for now. https://share.firefox.dev/3XPPKLS

Focusing on the 11 second jank in that profile and inverting stacks, it seems like we are spending 70% of our time waiting on a futex inside mozilla::ServoStyleSet::StyleDocument. In particular, this code looks like it is waiting for a long time.

I don't think this is JS-related. Redirecting to the CSS component.

(In reply to Iain Ireland [:iain] from comment #2)

Focusing on the 11 second jank in that profile and inverting stacks, it seems like we are spending 70% of our time waiting on a futex inside mozilla::ServoStyleSet::StyleDocument. In particular, this code looks like it is waiting for a long time.

I'm not an expert in our style system code, but I think there are other threads that aren't captured by default, which are actually doing restyle work in the background when the main thread appears to be hanging there. (They're called "StyleThread" in profiler UI, and aren't captured by default.)

That 11 second jank looks like it's actually a bunch of smaller restyles, from a bunch of zoom operations (via the site responding to a bunch of consecutive mousewheel scrolls -- e.g. a mousewheel "fling" or large-spin).

This jank doesn't seem to be a Firefox-specific badness -- zooming on the site is quite janky in Chrome, too -- on my machine, at least. In Chrome it's often actually a bit worse. If I scroll an individual mousewheel-tick, or if I use the "+" / "-" zoom buttons at the top left of the page, Chrome seems to take ~2x as long to repaint as compared to Firefox. (Chrome takes roughly 1s to respond, Firefox takes 0.5s, or in that rough ballpark.) Epiphany (WebKit) performs similarly to Chrome, too.

gregp, would you mind comparing to Firefox & seeing if this^ matches your experience? If you're seeing Firefox-specific badness here, then that's potentially something to investigate; but otherwise maybe we can close this as WORKSFORME (with the remaining jank assumed to just be the site doing tons of work, which is slow in any browser).

When I first looked at this bug, Firefox was much worse at zooming, now it seems significantly better than Chrome. Perhaps the Speedometer3 work has helped this case, or Chrome has gotten worse, or both :D

The only difference I see left is that dragging the fully zoomed out map janks in Firefox, which seems to not happen in Chrome.

STR:

1. Press the minimize (—) button at the top left corner of the page until you've reached the smallest size the map can be
2. Click and drag the map back and forth

https://share.firefox.dev/42KvU84

(In reply to Gregory Pappas [:gregp] from comment #4)

When I first looked at this bug, Firefox was much worse at zooming, now it seems significantly better than Chrome. Perhaps the Speedometer3 work has helped this case, or Chrome has gotten worse, or both :D

H... hooray? :)

The only difference I see left is that dragging the fully zoomed out map janks in Firefox, which seems to not happen in Chrome.

I noticed that clicking and dragging felt a bit laggier in Firefox, too. From your profile, it looks like that's WebRender stuff.

I'm just going to file that as a new bug and I'm gonna close this one as WORSKFORME, to avoid taking this one through too many incarnations (from a general Firefox 45 bug with a different URL for this stie, to a JS bug to a CSS bug, now to a WebRender bug. :)).