896076 - We are slow on SVG animation benchmark

Status: RESOLVED DUPLICATE of bug 1001593

(Core :: Graphics, defect)

Description

[Andreas Gal :gal]

I googled "SVG benchmark" and this is the first hit:

themaninblue.com/experiment/AnimationBenchmark/svg/‎

I have no idea how relevant this benchmark is, but we are 4x slower on Mac than Safari, so I grabbed a profile.

Comment 1

[Andreas Gal :gal]

The first thing that sticks out is that we keep re-painting the background (nsDisplayCanvasBackgroundColor). I would have thought we turn that into a color layer and repaint only on top of it.

Running Time	Self		Symbol Name
18418.0ms   69.8%	0.0	 	Main Thread  0x49cd4
13955.0ms   52.9%	0.0	 	 start
13955.0ms   52.9%	0.0	 	  main
13955.0ms   52.9%	0.0	 	   XRE_main
13955.0ms   52.9%	0.0	 	    XREMain::XRE_main(int, char**, nsXREAppData const*)
13955.0ms   52.9%	0.0	 	     XREMain::XRE_mainRun()
13955.0ms   52.9%	0.0	 	      nsAppStartup::Run()
13955.0ms   52.9%	0.0	 	       nsAppShell::Run()
13954.0ms   52.9%	1.0	 	        -[NSApplication run]
13943.0ms   52.8%	0.0	 	         -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
13943.0ms   52.8%	0.0	 	          -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
13940.0ms   52.8%	0.0	 	           _DPSNextEvent
13936.0ms   52.8%	0.0	 	            BlockUntilNextEventMatchingListInMode
13936.0ms   52.8%	0.0	 	             ReceiveNextEventCommon
13934.0ms   52.8%	0.0	 	              RunCurrentEventLoopInMode
13932.0ms   52.8%	0.0	 	               CFRunLoopRunSpecific
13922.0ms   52.8%	0.0	 	                __CFRunLoopRun
13891.0ms   52.6%	0.0	 	                 __CFRunLoopDoSources0
13887.0ms   52.6%	0.0	 	                  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
13886.0ms   52.6%	0.0	 	                   nsAppShell::ProcessGeckoEvents(void*)
13878.0ms   52.6%	0.0	 	                    nsBaseAppShell::NativeEventCallback()
13878.0ms   52.6%	0.0	 	                     NS_ProcessPendingEvents(nsIThread*, unsigned int)
13878.0ms   52.6%	0.0	 	                      nsThread::ProcessNextEvent(bool, bool*)
13710.0ms   52.0%	0.0	 	                       nsTimerEvent::Run()
13709.0ms   51.9%	0.0	 	                        nsTimerImpl::Fire()
13504.0ms   51.2%	0.0	 	                         mozilla::RefreshDriverTimer::Tick()
13500.0ms   51.2%	2.0	 	                          nsRefreshDriver::Tick(long long, mozilla::TimeStamp)
12683.0ms   48.1%	1.0	 	                           nsViewManager::ProcessPendingUpdatesForView(nsView*, bool)
12643.0ms   47.9%	1.0	 	                            PresShell::Paint(nsView*, nsRegion const&, unsigned int)
12623.0ms   47.8%	2.0	 	                             nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, unsigned int)
12285.0ms   46.5%	0.0	 	                              nsDisplayList::PaintRoot(nsDisplayListBuilder*, nsRenderingContext*, unsigned int) const
12284.0ms   46.5%	0.0	 	                               nsDisplayList::PaintForFrame(nsDisplayListBuilder*, nsRenderingContext*, nsIFrame*, unsigned int) const
11063.0ms   41.9%	0.0	 	                                mozilla::layers::ClientLayerManager::EndTransaction(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags)
11043.0ms   41.8%	0.0	 	                                 mozilla::layers::ClientLayerManager::EndTransactionInternal(void (*)(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags)
11040.0ms   41.8%	0.0	 	                                  ClientContainerLayer::RenderLayer()
11039.0ms   41.8%	1.0	 	                                   ClientContainerLayer::RenderLayer()
11038.0ms   41.8%	0.0	 	                                    mozilla::layers::ClientThebesLayer::RenderLayer()
11037.0ms   41.8%	0.0	 	                                     mozilla::layers::ClientThebesLayer::PaintThebes()
10696.0ms   40.5%	0.0	 	                                      mozilla::layers::ClientThebesLayer::PaintBuffer(gfxContext*, nsIntRegion const&, nsIntRegion const&, nsIntRegion const&, bool)
10686.0ms   40.5%	60.0	 	                                       mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*)
5632.0ms   21.3%	5.0	 	                                        nsDisplaySVGPathGeometry::Paint(nsDisplayListBuilder*, nsRenderingContext*)
4916.0ms   18.6%	0.0	 	                                        nsDisplayCanvasBackgroundColor::Paint(nsDisplayListBuilder*, nsRenderingContext*)
4916.0ms   18.6%	1.0	 	                                         nsRenderingContext::FillRect(nsRect const&)
4914.0ms   18.6%	0.0	 	                                          gfxContext::Fill()
1.0ms    0.0%	0.0	 	                                          gfxContext::Rectangle(gfxRect const&, bool)

Comment 2

[Andreas Gal :gal]

There is about an equal cost painting SVG stuff. Again we are not layerizing anything and just paint when positions change. Thats probably also not really awesome.

Last but not least there is also some heavy JS cost doing string to float conversion within set attribute calls on the SVG DOM.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

(In reply to Andreas Gal :gal from comment #2)
> There is about an equal cost painting SVG stuff. Again we are not layerizing
> anything and just paint when positions change. Thats probably also not
> really awesome.

Safari looks to be doing the same on my machine. So I'm not that concerned about this.

Here are some observations from comparing our profile with Safari's

                 Safari  FF
fillEllipse:     31%     26%
paintBackground: 3.5%    11%

The amount of time we spend in paintBackground is weird.
Both Safari and us spend all of our time in sse64CSGFill8by1 which is basically just memset. The only thing that I could come up with here is that Safari is always painting into the same buffer and not getting cache misses where as we paint into different buffers and have a cache disaster.

Comment 4

[Andreas Gal :gal]

Hi Jeff. Thanks for the diagnosis! I am not really concerned either. This test case hits SVG animation. I will look for something that pushes SVG painting itself more (since that came up on dev-gaia). I will leave this open for future reference, but I agree that there isn't that much to do here right now. The background painting goes away if I add a MarkLayersActive() in AttributeChange().

Comment 5

[Chris Peterson [:cpeterson]]

Bug 1001593 tracks a more recent perf regression in this same SVG animation benchmark. I assume any optimization for this benchmark will happen in that bug.