577069 - Regression: FishIE Tank performance significantly worse

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[nathaniel]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100705 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100705 Minefield/4.0b2pre

The FishIE Tank performance test for the IE9 preview tanked in performance recently from its outstanding capabilities last week.

Reproducible: Always

Steps to Reproduce:
1.Visit http://ie.microsoft.com/testdrive/Performance/FishIE%20tank/Default.html
2.Click 250, 500, or 1000 on the right
Actual Results:  
Get under 60 frames per second

Expected Results:  
Last week (with hardware acceleration enabled) it was 60 frames per second for 250 and 500, and 1000 was around 52. Firefox was actually outperforming IE9preview3.

Computer specs: Core i5 750; NVidia GeForce 275 GTX.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Nathaniel, are you willing to narrow down which nightly the problem first appeared in?

Comment 2

[nathaniel]

(In reply to comment #1)
> Nathaniel, are you willing to narrow down which nightly the problem first
> appeared in?

Ok, here's the timeline. (And a slight correction.)
June: 60fps for 250 and under; 42fps for 500, 24fps for 1000.
July 1st: 36fps for 250; 20 for 500; 11fps for 1000
July 2nd: Hardware acceleration appears to not load, as every test (not just the fish tank) gets incredibly worse (in the fish tank demo's case it was doing below 60 at a much lower number). Other evidence that hardware accelerated graphics is not working is in the text rendering demo where transitions weren't subpixel smooth, but instead choppy. (http://ie.microsoft.com/testdrive/Performance/12ScrollingText/Default.xhtml)
July 3rd: Hardware acceleration loads again, getting the same performance as July 1st.

Hope that's helpful. :)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Nathaniel, what are the build ids (the http://... part in about:buildconfig) of the last build which works well for you and the JulY 1 build that doesn't work?

Comment 4

[Bas Schouten (:bas.schouten)]

I'm pretty sure this is caused by anti-aliased clipping being fix. There's probably something easy we can do to canvas DrawImage to counter this regression. Testing.

Comment 5

[nathaniel]

(In reply to comment #3)
> Nathaniel, what are the build ids (the http://... part in about:buildconfig) of
> the last build which works well for you and the JulY 1 build that doesn't work?

June 30th) http://hg.mozilla.org/mozilla-central/rev/580205b95ceb
July 1st) http://hg.mozilla.org/mozilla-central/rev/82edf5bd1abe

Bas Schouten) Yes, it does seem to be related to anti-aliased clipping being fixed, since the first build I found it in, that was fixed. I remembering thinking this was probably the case.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Range from comment 5: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=580205b95ceb&tochange=82edf5bd1abe

That does look like antialiased clipping is in the range (as well as things like the e10s merge, etc...).

Comment 7

[José Jeria]

See bug 567295 comment 33 and bug 567295 comment 36

Comment 8

[Bas Schouten (:bas.schouten)]

Shit should be tested after landing the fix to bug 583033. It seems to have improved for me.

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to comment #8)
> Shit should be tested after landing the fix to bug 583033. It seems to have
> improved for me.

Erm, obviously, this, should be tested.

Comment 10

[José Jeria]

Bug 583033 improved the performance. 

IE is still faster though

Fishes	Firefox 4	IE 9
100	46 fps		60 fps
250	25 fps		55 fps

Comment 11

[Bas Schouten (:bas.schouten)]

Together with Jeff's Canvas patch to switch clip->paint to fill for the alpha == 1.0 case the performance of this test is back to being good.

Comment 12

[nathaniel]

I tried the nightly today and I still get 44FPS for 250. Recall my original report where it was at 60fps for 250. It is a little better (44>36), but not by much, and definitely did not catch up to previous performance.

Comment 13

[José Jeria]

(In reply to comment #12)
Wait for bug 576169 to land

Comment 14

[Bas Schouten (:bas.schouten)]

This should be tested with bug 576169.

Comment 15

[José Jeria]

(In reply to comment #14)
> This should be tested with bug 576169.

This is back to normal now. Even faster than IE 9!

Comment 16

[José Jeria]

I believe that this bug should be closed now, since the regression is now gone.