IE Maze solver painting is slow

NEW
Unassigned

Status

()

Core
Layout: View Rendering
6 years ago
a month ago

People

(Reporter: bz, Unassigned)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: ietestdrive, URL)

Attachments

(3 attachments)

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.
See Also: → bug 641341
See Also: → bug 641340
It's possible that we're still doing some reflow here (see bug 524925).  Odd that I did not see it in my profile....
Depends on: 524925
The MazeContainer is float: left so if we reflow anything inside it we will invalidate the whole maze because of this code http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsBlockFrame.cpp#2505 , no?
Could be, yes.  Hence the dependency.

Updated

6 years ago
Whiteboard: ietestdrive
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.
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.
Created attachment 599973 [details]
profile call graph, as plain text (xz compressed)

Just uncompress with xz -d, this is a plain text file.
Created attachment 599974 [details]
flat profile, just plain text (for the lazy!)

Use that if you can't be bothered to use xz -d ;-)
Has anyone had time to look at the profiles?
We've been hit again by this bug in this new Browser Grand Prix:
http://www.tomshardware.com/reviews/windows-xp-web-browser-performance,3167-8.html
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.
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.
Depends on: 539356
Oh, and maybe we do just need a single tracker bug for this testcase....
Blocks: 776190
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

5 years ago
DLBI, as landed today (cset 75cdb3f932c6), only marginally fixes this.

On my WinXP system, Firefox takes 49 seconds, whereas Chrome takes 6.1 seconds.
DBLI has definitely not landed today. Only some parts landed, and not the parts that help with this bug.

Comment 15

5 years ago
I'm now seeing 7,4 seconds on Nightly, excellent progress!

Comment 16

5 years ago
i am seeing much better performance now on a 40x40 maze. Excellent work!

Comment 17

5 years ago
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.
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.
Are you testing with a nightly that has bug 642257 (so 2012-10-19 or newer)?
I was testing with yesterday's nightly, I am going to test today's and report back.
(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

5 years ago
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 10.1.4.38
Adobe Acrobat 11.0.0.379
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 6.2.0.5788
Google Shortcuts 2.1.7.1
Google Update 1.3.21.123
HP Smart Web Printing 4.5 [DISABLED]
Implicit 19.0a1
Java Deployment Toolkit 7.0.70.11 10.7.2.11
Java(TM) Platform SE 7 U7 10.7.2.11
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 7.17.13.697
NVIDIA 3D VISION 7.17.13.697
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 2.0.2.0
Yahoo Application State Plugin 1.0.0.7
Blocks: 918620
This CSS3 layout benchmark is slower when Stylo is enabled. Results for solving the large 40x40 maze on my Windows 10 laptop:

Firefox 54 = 20 seconds
Firefox Nightly 56 without Stylo = 17 seconds
Firefox Nightly 56 with Stylo pref enabled = 21 seconds
Edge = 31 seconds
Chrome Beta 60 = 6.4 seconds!
Blocks: 1289864
status-firefox54: --- → affected
status-firefox55: --- → affected
status-firefox56: --- → affected
OS: Mac OS X → All
Hardware: x86 → All
Summary: IE Maze solver painting is slow → IE Maze Solver CSS3 Layout Performance Test is slower in Stylo than Gecko (and 3x slower than Chrome)
We're still not ready for people to run performance benchmarks on stylo. We need Manish to land his stuff and do a few other things before any performance comparisons will be meaningful.
Please do not hijack bugs.  This bug was about a specific issue which had nothing to do with stylo.  Please file a separate bug for whatever stylo issue you see.
No longer blocks: 1289864
status-firefox54: affected → ---
status-firefox55: affected → ---
status-firefox56: affected → ---
Summary: IE Maze Solver CSS3 Layout Performance Test is slower in Stylo than Gecko (and 3x slower than Chrome) → IE Maze solver painting is slow
You need to log in before you can comment on or make changes to this bug.