Last Comment Bug 691645 - IE Maze solver painting is slow
: IE Maze solver painting is slow
Status: NEW
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 11 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on: 524925 dlbi
Blocks: 776190 ietestdrive
  Show dependency treegraph
Reported: 2011-10-03 19:53 PDT by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2013-09-19 19:30 PDT (History)
19 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

raw data from 'perf' (you need perf to use that) (71.12 KB, application/x-xz)
2012-02-23 06:19 PST, Benoit Jacob [:bjacob] (mostly away)
no flags Details
profile call graph, as plain text (xz compressed) (64.82 KB, application/x-xz)
2012-02-23 06:21 PST, Benoit Jacob [:bjacob] (mostly away)
no flags Details
flat profile, just plain text (for the lazy!) (132.80 KB, text/plain)
2012-02-23 06:22 PST, Benoit Jacob [:bjacob] (mostly away)
no flags Details

Description Boris Zbarsky [:bz] (still a bit busy) 2011-10-03 19:53:18 PDT
I tried working around bug 641340 by simply sticking "-moz-transform: translate(0,0)" in the rule for .marker using DOM Inspector.

If I do that, we're still slow, but now it's all painting (building display lists and the actual painting we do).  I wonder why we end up invalidating more than just the markers that actually get moved...  I tried turning off hardware acceleration and using the Quartz Debug paint flashing, and the whole maze flashes a good bit.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-10-03 20:23:31 PDT
It's possible that we're still doing some reflow here (see bug 524925).  Odd that I did not see it in my profile....
Comment 2 Timothy Nikkel (:tnikkel) 2011-10-03 20:44:43 PDT
The MazeContainer is float: left so if we reflow anything inside it we will invalidate the whole maze because of this code , no?
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-10-03 20:46:24 PDT
Could be, yes.  Hence the dependency.
Comment 4 Benoit Jacob [:bjacob] (mostly away) 2012-02-23 06:18:05 PST
This test is repeatedly being used as a benchmark in editions of Tom's Hardware's  "Web Browser Grand Prix" so it's worth having a closer look at. Profile data coming.
Comment 5 Benoit Jacob [:bjacob] (mostly away) 2012-02-23 06:19:54 PST
Created attachment 599972 [details]
raw data from 'perf'  (you need perf to use that)

Uncompress with xz -d, and run `perf report` in the same directory.

If you don't have perf / are not on Linux, plain text files are coming.
Comment 6 Benoit Jacob [:bjacob] (mostly away) 2012-02-23 06:21:13 PST
Created attachment 599973 [details]
profile call graph, as plain text (xz compressed)

Just uncompress with xz -d, this is a plain text file.
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2012-02-23 06:22:14 PST
Created attachment 599974 [details]
flat profile, just plain text (for the lazy!)

Use that if you can't be bothered to use xz -d ;-)
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2012-04-17 22:23:58 PDT
Has anyone had time to look at the profiles?
We've been hit again by this bug in this new Browser Grand Prix:,3167-8.html
Comment 9 Timothy Nikkel (:tnikkel) 2012-04-17 22:29:48 PDT
There has been work on this, but it happened off of bug 641341. Specifically bug 730769 and bug 730771. The bugs show that Mats has done some of his own profiling, and bz has profiled this before too.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2012-04-18 08:27:29 PDT
What comment 9 said.  But more importantly, we've been hit by this _testcase_.  There are a number of separate performance issues here (see also the bug linked in comment 0), which we're working on fixing one by one.  This bug is about the painting parts specifically.  It's possible that bug 539356 will more or less ameliorate it.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2012-04-18 08:31:08 PDT
Oh, and maybe we do just need a single tracker bug for this testcase....
Comment 12 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-08-07 14:50:54 PDT
The worst of the over-invalidation is because of this code in nsFrame::InvalidateInternalAfterResize:
    nsRect newDamageRect = nsDisplayTransform::TransformRectOut
                             (aDamageRect, this, nsPoint(-aX, -aY));
    if (!(GetStateBits() & NS_FRAME_SVG_LAYOUT)) {
      newDamageRect.UnionRect(newDamageRect, aDamageRect);
Basically, because callers of Invalidate are confused about whether the incoming rect is before applying transforms or after applying transforms, we're super-conservative here and assume it could be either. We can improve this, but DLBI will fix it too, so I think we should just focus on finishing DLBI.
Comment 13 IU 2012-08-13 17:24:43 PDT
DLBI, as landed today (cset 75cdb3f932c6), only marginally fixes this.

On my WinXP system, Firefox takes 49 seconds, whereas Chrome takes 6.1 seconds.
Comment 14 Robert O'Callahan (:roc) (email my personal email if necessary) 2012-08-13 23:12:12 PDT
DBLI has definitely not landed today. Only some parts landed, and not the parts that help with this bug.
Comment 15 Dennis Jakobsen 2012-08-15 03:52:38 PDT
I'm now seeing 7,4 seconds on Nightly, excellent progress!
Comment 16 mayankleoboy1 2012-08-19 07:10:25 PDT
i am seeing much better performance now on a 40x40 maze. Excellent work!
Comment 17 Dennis Jakobsen 2012-10-09 06:38:12 PDT
I'm seeing a consistent 6 second run on 40x40 even with paintflashing on. DLBI is still over-invalidating in the 40x40 maze, but i'll report that in dlbi.
Comment 18 Pascal Chevrel:pascalc 2012-10-19 07:53:26 PDT
I am noticing something interesting with this perf testcase and its interaction with Flash and Facebook, it may be another bug affecting the overall performance of this specific test though, just tell me if I need to open a separate bug.

Here is what I am seeing: 
- if I only have the IE Maze page open in Nightly on Linux, I get results around 12 seconds for the 30x30 maze
- if I also have a facebook tab open + flash activated, the same 30x30 maze is 112 second
- if I disable Flash in about:plugins, I get results around 12s with or without a Facebook tab open
- If I activate Flash, have a flash video on youtube in a tab running, no facebook page open and run the IE maze, I get about 14s

That makes:

It seems that Facebook is using Flash in ways that impact painting a lot in the IE maze tab.
Comment 19 Timothy Nikkel (:tnikkel) 2012-10-19 09:54:18 PDT
Are you testing with a nightly that has bug 642257 (so 2012-10-19 or newer)?
Comment 20 Pascal Chevrel:pascalc 2012-10-19 10:20:31 PDT
I was testing with yesterday's nightly, I am going to test today's and report back.
Comment 21 Pascal Chevrel:pascalc 2012-10-19 10:30:20 PDT
(In reply to Timothy Nikkel (:tn) from comment #19)
> Are you testing with a nightly that has bug 642257 (so 2012-10-19 or newer)?

This is fixed with today's nightly, so that was the bug I was seeing :)
Comment 22 Raul Malea 2012-10-19 10:46:14 PDT
Maze 30x30 - 6 seconds with more tabs activated (including Facebook)
Maze 40x40 - 10 seconds

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121019030551

about:me 0.5
Adblock Plus 2.1.2
Add-on Compatibility Reporter 1.1
Adobe Acrobat - Create PDF 1.2
Adobe Acrobat
Adobe Acrobat
ANIMATED - Snowflake Village 1320945460 [DISABLED]
British English Dictionary 1.19.1
Bugzilla Tweaks 1.12.1
Cheevos 1.4
Collusion 0.16.3 [DISABLED]
Dicționar românesc de corectare ortografică. 1.12
Download Statusbar 0.9.10
fireblur 1260925626 [DISABLED]
Google Earth Plugin
Google Shortcuts
Google Update
HP Smart Web Printing 4.5 [DISABLED]
Implicit 19.0a1
Java Deployment Toolkit
Java(TM) Platform SE 7 U7
Microsoft Office 2010 14.0.4730.1010
Microsoft Office 2010 14.0.4761.1000
Mozilla QA Companion 1.2.3
Mozilla Reps Companion 1.1
MozMill 1.5.19
Mozmill Crowd 0.1.5
Nightly Tester Tools 3.3
NoScript 2.5.8
NVIDIA 3D Vision
Puppy Dogs... 1291695684 [DISABLED]
Sage 1.4.12
Shockwave Flash 11.4.402.287
Silverlight Plug-In 5.1.10411.0
Submit Word 1.1.0
Test Pilot 1.2.2
VLC Web Plugin
Yahoo Application State Plugin

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