Last Comment Bug 526380 - Polyfield example is much faster in webkit
: Polyfield example is much faster in webkit
Status: NEW
[in-the-wild][perf:painting]
: perf
Product: Core
Classification: Components
Component: SVG (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://mrdoob.com/lab/javascript/poly...
Depends on: skia-osx
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-03 17:48 PST by Jonathan Watt [:jwatt]
Modified: 2016-06-13 09:29 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Jonathan Watt [:jwatt] 2009-11-03 17:48:16 PST
The linked polyfield example is currently much faster in webkit.
Comment 1 User image Jonathan Watt [:jwatt] 2009-11-03 17:51:20 PST
The poor FF perf doing the twitter rounds. :-/ e.g. http://twitter.com/UnitZeroOne/status/5400573136
Comment 2 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2009-11-03 18:33:07 PST
Are you going to analyze this?
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2009-11-03 19:12:27 PST
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 User image Boris Zbarsky [:bz] (still a bit busy) 2009-11-03 19:22:40 PST
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 User image Jonathan Watt [:jwatt] 2012-03-22 15:18:19 PDT
URL is dead. :(
Comment 6 User image Jonathan Watt [:jwatt] 2012-05-02 08:18:02 PDT
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 User image Jonathan Watt [:jwatt] 2013-01-09 08:04:43 PST
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 User image Jonathan Watt [:jwatt] 2014-10-04 10:27:59 PDT
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 User image Jeff Muizelaar [:jrmuizel] 2014-10-06 07:56:31 PDT
(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 User image Jonathan Watt [:jwatt] 2016-06-13 09:28:55 PDT
We're now also using Skia on OS X. We should retest this.

Note You need to log in before you can comment on or make changes to this bug.