1348607 - Mr.doob SVG benchmark is 4x slower in Firefox than Chrome on Mac

Status: RESOLVED WORKSFORME

(Core :: SVG, defect, P3)

Description

[Jonathan Watt [:jwatt]]

+++ This bug was initially created as a clone of Bug #526380 +++

http://mrdoob.com/lab/javascript/benchmark/svg/

During each "frame" (setInterval callback) the test removes all the graphic elements from the document and then creates and inserts a new set of graphic elements. The number of SVG <path> elements that are being removed and regenerated each "frame" is 500, so it's not a huge number, although they pretty much fill the entire content area.

Comment 1

[Jonathan Watt [:jwatt]]

A profile shows we're spending pretty much all our time under DrawTargetSkia::Fill/SkCanvas::onDrawPath:

https://perfht.ml/2nQRPpZ

I believe Chrome also is using Skia to paint, so I'm not sure why they would be 4x faster unless they have their GPU backend enabled. Lee, would you know?

Comment 2

[Lee Salzman [:lsalzman]]

Well, looking at the benchmark and the profile, it looks like that since these paths it is drawing are random triangles, they can't get simplified to rects and go through the FillRect fast-path. Once there, it is spending some notable time anti-aliasing the edges of the triangles, but nowhere near enough to in any way be the cause of the 4x slowdown. Otherwise, we're just dying the normal fill-rate death of drawing a lot of big stuff on screen.

So the only explanation that would make any sense would be if Chrome was in fact using the GPU to draw things, since everything looks proper in terms of which codepaths Skia is running through. There is nothing that looks obviously "wrong" in the profile.

Comment 3

[Jan Bösenberg]

On my machine (Windows 7, Firefox 60) the frame rates are in the same ballpark, Chrome maybe about 10-15% faster than Firefox. This is nowhere the original reported factor 4 anymore.