User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Hi, I'd like to report significant difference in performance on Canvas operations between Firefox and Chrome. The original issue for this was at https://github.com/williamngan/pts/issues/107 and Eric Smyth advised to report it here.

After doing some research, I found a few similar reports:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1195633 (closed 5y ago, no resolution)
• https://bugzilla.mozilla.org/show_bug.cgi?id=1360222 (open)
• https://bugzilla.mozilla.org/show_bug.cgi?id=1593612 (open, meta)

Basically, several people have been observing big difference in FPS on canvas animations between Firefox and Chrome. I have recorded and shared some profiles on both browsers to help identify the source and it seems to point to FF internals. The perf difference is pretty astounding, the same animation frames is processed in less than 5ms on Chrome, while Firefox take over 20ms, sometimes close to 30ms. This applies to several codebases, including my own (closed source / access), so I recorded profiles on a publicly accessible site: https://ptsjs.org/.

Actual results:

I've recorded and published a profiler session of the https://ptsjs.org on Firefox at https://profiler.firefox.com/public/dj5pyn3643pv7jtx07w5nm98zccyy085wc0f8dr. By looking at it, DOM operations are taking 74% of the CPU time on frame requests.

I've then done the same in Chrome. You can open it by going at https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://www.dropbox.com/s/k5nh8s72n7nc2tq/chrome-profiler-ptsjs.json?dl=0. Note that this link only works on Chrome.

Comparing the recordings is not easy as both browsers are not recording the same thing. The easiest I've found is comparing Firefox's stack chart to Chrome's "Main" graph. There I'd advise to zoom or select a part of the timeline that covers a single animation frame request. The ones I've zoomed in take respectively 19ms and 5ms. The difference seems to come from the large blue blocks (DOM) in Firefox which do not seem to appear at all on Chrome. I'm not sure if the performance is really drastically different or if the browsers are just not recording things the same way. If they are indeed comparable, then it would seem the difference is at the DOM level.

I've tried further to focus on JS operations (not DOM) and get a sense of time spent. In this particular animation, perpendicularFrom is a time consuming ptsjs calculation which doesn't involve rendering. By looking at the Call Tree in Firefox, we can find it and it has a total runtime of 2ms during a single animation frame. On the Chrome side, I've used the Bottom-Up tab and found that it has a total runtime of 1.7ms. That difference seems irrelevant compared to the order of magnitude found previously, I'd say it points to performance issues coming from the browser.

Expected results:

Hopefully, we can get closer to performance parity between browsers 😬.

@lsalzman: This looks like a serious performance issue and easily reproduced (only tried with WR). Could you take a look what would be causing this?

This is SkiaGL vs software canvas performance. Filing against the tracking bug.