When I click on a tab in the Panorama view, and the zoom-in transition animates, it's terribly slow. It looks like I get 2 or 3 animation frames at most. On my Linux and Mac machines it's much smoother. I'm on a Core 2 Duo, 4GB ram. My graphics card is a Radeon X1300/X1550 Series, with the WDDM drivers. I'm running Windows 7 x64. I don't have D2D enabled (my card is only a DX9 card, I've been told), but I do have DWrite enabled.

How about if you enable D3D9? Try MOZ_ACCELERATED=1

Seems slightly better, although still not as fast as on Linux (where I'm using Intel onboard video), or on Mac (where it's smooth like butter).

Ted, what's in your graphics section of about:support?

Adapter Description Radeon X1300/X1550 Series (Microsoft Corporation - WDDM) Vendor ID 1002 Device ID 7183 Adapter RAM Unknown Adapter Drivers atiumdag atiumdva atiumd64 atiumd6a atitmm64 Driver Version 8.56.1.15 Driver Date 4-24-2009 Direct2D Enabled false DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 9

We need D3D9 at least to be fast at this.

Did you intentionally flip the moco confidential flag here? (I'm guessing not...)

nope! crap.

So, I could easily reproduce this in Mac and Windows. Both show kind of the same behavior on heavy-weight web pages. One good web page to reproduce this on is twitter.com. Aza, Ian, I think we should sit down next week and discuss how we can make stuff better here. I have a few ideas about starting the reflow (and/or paint) process earlier than when we actually start the zooming operation, because the bottleneck here seems to be the amount of time we spend on painting the full size page again when the animation is finished. Can we do that next week?

Interesting... we actually have been repainting the thumbnails speculatively (before any zoom is requested) so we don't have to do a repaint once we know we need to zoom. That's actually going to change, however, with bug 609685. Also note that we're thinking about using WebGL for the zoom (bug 617463). At any rate, if you've got ideas for speeding up our zoom animation, I'm all for it!

(In reply to comment #9) > Interesting... we actually have been repainting the thumbnails speculatively > (before any zoom is requested) so we don't have to do a repaint once we know we > need to zoom. Hmm, that might have lead to painting too soon. Has that actually improved performance? Which bug did make that change? > That's actually going to change, however, with bug 609685. How is this going to change? Any change here should be evaluated to make sure that it doesn't regress performance. > Also note that we're thinking about using WebGL for the zoom (bug 617463). I talked that out with the gfx guys, that's not gonna help at all, and at this point I don't think it's something that we want to do. > At any rate, if you've got ideas for speeding up our zoom animation, I'm all > for it! Well, we should first talk about how things work, to enable me understand everything I need to know without reading the entire code. Once I have that understanding, I will come up with a set of concrete suggestions which we can try and measure the performance benefit of each one.

(In reply to comment #10) > (In reply to comment #9) > > Interesting... we actually have been repainting the thumbnails speculatively > > (before any zoom is requested) so we don't have to do a repaint once we know we > > need to zoom. > > Hmm, that might have lead to painting too soon. Has that actually improved > performance? Which bug did make that change? That's the way it's been since the beginning. > > That's actually going to change, however, with bug 609685. > > How is this going to change? Any change here should be evaluated to make sure > that it doesn't regress performance. With that patch we'll be doing a canvas drawWindow call (with no layout flush) right at the beginning of the zoom. Sean says this doesn't seem to make the zoom any chunkier, but we don't really have a good objective way to test "chunkiness". > Well, we should first talk about how things work, to enable me understand > everything I need to know without reading the entire code. Once I have that > understanding, I will come up with a set of concrete suggestions which we can > try and measure the performance benefit of each one. Sounds good; find me on IRC and we can chat or phone call. Thanks!

(In reply to comment #11) > > > That's actually going to change, however, with bug 609685. > > > > How is this going to change? Any change here should be evaluated to make sure > > that it doesn't regress performance. > > With that patch we'll be doing a canvas drawWindow call (with no layout flush) > right at the beginning of the zoom. Sean says this doesn't seem to make the > zoom any chunkier, but we don't really have a good objective way to test > "chunkiness". So, this was minused because it's just a small level of slowness, and not a huge performance hit. If one of the people on the Panorama team can find a web page on which this problem is much worse to the point of making the browser unusable, they should post the URL and renominate for blocking. Otherwise, I probably won't have enough time to look into this for Firefox 4, as I'm currently focused on blockers.

bugspam (moving b9 to b10)

bugspam (removing b9)

This feels like a amorphous bug description, imho... but adding to our beta 11 tracking bug for profiling work, in case someone wants to take it up. (In reply to comment #12) > Otherwise, I > probably won't have enough time to look into this for Firefox 4, as I'm > currently focused on blockers. Unassigning you, then. Adding the rest of the Panorama Perf All-Star Team.

Too late for this for Fx4

We're not going to address this with Panorama being slated for removal.