526380 - Polyfield example is much faster in webkit

Status: RESOLVED INCOMPLETE

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

The linked polyfield example is currently much faster in webkit.

Comment 1

[Jonathan Watt [:jwatt]]

The poor FF perf doing the twitter rounds. :-/ e.g. http://twitter.com/UnitZeroOne/status/5400573136

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are you going to analyze this?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Jonathan Watt [:jwatt]]

URL is dead. :(

Comment 6

[Jonathan Watt [:jwatt]]

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.

Comment 7

[Jonathan Watt [:jwatt]]

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.

Comment 8

[Jonathan Watt [:jwatt]]

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?

Comment 9

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 10

[Jonathan Watt [:jwatt]]

We're now also using Skia on OS X. We should retest this.

Comment 11

[Jonathan Watt [:jwatt]]

Enough has changed that it's worth closing this bug and opening another. I opened bug 1348607.