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

NEW
Unassigned

Status

()

Core
SVG
P3
normal
a year ago
10 months ago

People

(Reporter: jwatt, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [in-the-wild][perf:painting], URL)

(Reporter)

Description

a year ago
+++ 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.
(Reporter)

Comment 1

a year ago
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?
Flags: needinfo?(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.
Flags: needinfo?(lsalzman)

Updated

10 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.