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.
Nathaniel, are you willing to narrow down which nightly the problem first appeared in?
(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. :)
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?
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.
(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.
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...).
Shit should be tested after landing the fix to bug 583033. It seems to have improved for me.
(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.
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
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.
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.
This should be tested with bug 576169.
(In reply to comment #14) > This should be tested with bug 576169. This is back to normal now. Even faster than IE 9!
I believe that this bug should be closed now, since the regression is now gone.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.