We saw this when turning on by default. Regression: Txul increase 21.2% on Win7 Firefox Previous results: 85.8333 from build 20100813230431 of revision 17f4064c1d23 at 2010-08-14 00:21:09 on talos-r3-w7-017 run # 0 New results: 104.053 from build 20100814003550 of revision 536ac334d335 at 2010-08-14 02:01:56 on talos-r3-w7-033 run # 0 http://mzl.la/aNtHR3 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=17f4064c1d23&tochange=536ac334d335

So this looks like regression of about 20ms. We need to figure out where that time is going and what we can do about it.

I've yet to know exactly what Txul measures, a couple of things come to mind: - Swap chain initialization (this shouldn't take 20ms) - Native theme drawing (it might be doing that, I don't know, if it is, I created a patch yesterday that will speed the problematic alpha recovery algorithm up by some 6-8 times here) We'll need to analyze the test more extensively to understand what's going on here. I'd argue for now there's more important issues with D2D performance. And with 130078 window creation should be a much more rare occasion.

I've run this locally on a release build I have, got me results were as follows: GDI: 135,134,133,133,133,134,134,132,133 D2D: 112,113,116,122,105,106,121,106,105 So D2D was roughly 20ms -faster-, but both were slower than the runs on the Test machines. This might e. The improved native alpha recovery code didn't seem to make a difference. This was on a Core i7 920 with 6 Gb RAM in 3 channels and an HD5850 GPU. It should probably be faster than the Talos boxes which are mini's! Although the builds Talos runs gets profile guided optimizations where mine didn't, I'll try with an official Bo build later. fwiw the deviation on the D2D run was a lot larger as can be seen. I don't have a good explanation for that. One thing that is interesting to note that

Ugh, I was editting that, it was supposed to say 'This might be because the Talos runs we do don't have browser chrome.' And I was going to end with 'One thing that is interesting to note is that in my test these were measuring the speed of the animation of a new tab coming in as well, which might be why the D2D run was faster.'

Is there any Ts regression? Or just Txul? If just Txul, I think we ignore it rather than spend time on it at this point.

(In reply to comment #5) > Is there any Ts regression? Or just Txul? If just Txul, I think we ignore it > rather than spend time on it at this point. What's the rationale for that? We've bounced UI patches for increasing much smaller TXul regressions.

Mainly that the overall perf impact of having d2d enabled is (should be) very positive; as long as startup time isn't impacted, I think taking a hit on time to open a new window would be ok. UI changes that lead to Txul hits generally mean that our UI became more complex in some way that we should fix; the Txul hit here just means that the act of opening a window and initializing the stuff we need for it got more expensive. We should try to understand what's happening there, but it's probably going to be very hard for us to actually get that time back if it's somewhere in d2d/dx device/etc. init code. It'll also pretty heavily depend on the driver and its implementation; for example, Bas might be seeing a win on his machine which might have an optimized driver, whereas the tinderbox might be using an older/unoptimized/software whatever driver that introduces more cost.

Is this an across-the-board regression, or only on Windows? Sorry if this was made clear by an earlier comment....

(In reply to comment #8) > Is this an across-the-board regression, or only on Windows? Sorry if this was > made clear by an earlier comment.... D2D is windows only, the code is only compiled and run on windows. Other platforms are not affected.

Yeah, I know that part... it just wasn't clear to me that the changes made to support D2D were windows-only...

My results on a Mac Mini, again, with browser chrome: D2D: 193,206,186,196,184,212,221,197,280 GDI: 138,149,169,145,145,142,155,141,125 In other words, at this point on the Mac Mini, with a plain nightly, D2D performs significantly worse at this test than GDI. Since I do think this is interesting I'm going to do a little bit of investigation to see what is taking the time here.

Although I have no idea what I changed to make GDI so much faster than it was (as far as I know I changed nothing), the numbers in my latest test run are now as follows: D2D: 108,111,100,98,114,99,102,112,102 GDI: 95,94,85,85,84,85,85,85,86 So we can see the numbers are much like what they are on this bug now, with relation to performance difference. If we don't do the complex push/pop thing for doing borders with operator add, the numbers look like this for Txul: D2D: 75,75,77,77,76,77,79,77,75 GDI: 88,101,84,84,84,83,83,83,83 It looks like the D2D code here is partly limited by the speed of our border rendering code. See bug 588271.

Recent changes seemed to have dropped the regression to 18% Regression: Txul increase 18.1% on Win7 Firefox Previous results: 87.1579 from build 20100817192012 of revision f001894b50ea at 2010-08-17 20:41:42 on talos-r3-w7-046 run # 0 New results: 102.895 from build 20100817214337 of revision 984f55359541 at 2010-08-17 23:13:15 on talos-r3-w7-030 run # 0 http://mzl.la/apijw2

I'm hopeful Bug 585817 will prove helpful here.

This appears to be fixed with bug 585817 being solved.

Yeah, http://is.gd/eALhX bears out Bas's assertion in comment 15.