Polyfield example is much faster in webkit

RESOLVED INCOMPLETE

Status

()

Core
SVG
RESOLVED INCOMPLETE
8 years ago
a month ago

People

(Reporter: jwatt, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

8 years ago
The linked polyfield example is currently much faster in webkit.
(Reporter)

Comment 1

8 years ago
The poor FF perf doing the twitter rounds. :-/ e.g. http://twitter.com/UnitZeroOne/status/5400573136
Are you going to analyze this?
General outline, fwiw:

30% appending nodes to the DOM, almost all of it under nsSVGUtils::UpdateGraphic (which seems to be called via nsFrame::Init according to shark(???) and nsSVGDisplayContainerFrame::InsertFrames).

15% removing from the DOM, almost all under Invalidate() call nsFrameManager::RemoveFrame makes and the nsSVGDisplayContainerFrame::RemoveFrame call into ... nsSVGUtils::InvalidateCoveredRegion.

~15-20% running JS (3% on trace; 2% entering and leaving trace; you might want to file some bugs on the non-tracing bits).

7% setting attributes on DOM nodes; at least half of this is nsSVGDataParser::Parse called from nsSVGPathElement::BeforeSetAttr. This is mostly spending time under MatchSubPath.

About 10% painting.

Huge amounts of memory traffic: 5-6% of the time is mmap and munmap.
I'm seeing 5-6MB worth of nsSVGElement::UpdateContentStyleRule allocations and 12-13MB worth of setting attrs to strings.  Also 8 megs allocated from js_ValueToCharBuffer calling js_NumberValueToCharBuffer.  Might be worth looking into why that's happening.

4MB worth of NS_NewSVGPathElement.

Several MB of rects tossed into our invalidation regions, looks like.  -18MB from GC (actually freed some memory!).

If shark's not trying to me, about 2.5GB (over 30 seconds) of memory traffic from CGReleaseRegion and CGUnionRegionWithRect reallocing all over; nets out to 0, but might cost at the time...  That's from all the invalidation we're doing.
(Reporter)

Comment 5

5 years ago
URL is dead. :(
(Reporter)

Comment 6

5 years ago
Mr.doob suggested these as alternatives:

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

For 'random' I get about 25 "FPS" in Moz, Chrome and Opera (after letting it bring the shapes into view and then moving the mouse around).

For 'svg' I get roughly:

Moz:     6
Chrome: 11
Opera:  30

For 'svg_aliased' I get roughly:

Moz:    17
Chrome: 20
Opera:  30

I'm not sure I really trust the Opera numbers though, since it seems to be doing some weird interrupting of the script to draw...or something. This is most easily seen with 'random'. All three tests during each "frame" (setInterval callback) remove all the graphic elements from the document and then create and insert a new set of graphic elements. With 'random' you can clearly see that Opera isn't drawing all the elements every frame, which suggests it may be interrupting the script to draw. This would allow it to get a faster frame rate both by virtue of interrupting the script, and because it has to draw fewer shapes when it interrupts, since they haven't all been removed/added to the document.
(Reporter)

Comment 7

4 years ago
In the two examples from comment 6 where we're lagging behind other implementations ('svg' and 'svg_aliased') we are spending over 75% of the time in gfxContext::Fill(), suggesting that we're just slow to draw. (OS X 10.8.)

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 can fill the entire content area.
(Reporter)

Updated

4 years ago
Whiteboard: [in-the-wild]
(Reporter)

Comment 8

3 years ago
Now we're ever slower on Mac. Roughly 3x slower than the numbers I gave in comment 6 a couple of years ago.

Using the Gecko profiler with current Nightly on http://mrdoob.com/lab/javascript/benchmark/svg/ it looks like we're spending pretty much our entire time under DrawTargetCG::Fill.

Jeff, is there a reason Chrome's painting would be much faster than us here? If so, is there a bug for that?
Flags: needinfo?(jmuizelaar)
(Reporter)

Updated

3 years ago
Whiteboard: [in-the-wild] → [in-the-wild][perf:painting]
(In reply to Jonathan Watt [:jwatt] from comment #8)
> Now we're ever slower on Mac. Roughly 3x slower than the numbers I gave in
> comment 6 a couple of years ago.
> 
> Using the Gecko profiler with current Nightly on
> http://mrdoob.com/lab/javascript/benchmark/svg/ it looks like we're spending
> pretty much our entire time under DrawTargetCG::Fill.
> 
> Jeff, is there a reason Chrome's painting would be much faster than us here?
> If so, is there a bug for that?

Chrome is using Skia on OS X. That could be the reason. I'll take a look.
(Reporter)

Comment 10

11 months ago
We're now also using Skia on OS X. We should retest this.
Depends on: 1207332
(Reporter)

Updated

11 months ago
Flags: needinfo?(jmuizelaar)
(Reporter)

Comment 11

a month ago
Enough has changed that it's worth closing this bug and opening another. I opened bug 1348607.
Status: NEW → RESOLVED
Last Resolved: a month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.