Summary pretty much covers it. Shaver requested I file this. URL: http://patrickfinch.com/2010/09/02/still-thinking-about-the-open-web/

Can you load that page and try this bookmarklet? javascript:void((function(){var%20i=0;var%20start=Date.now();function%20f(){if(++i==50){alert((Date.now()-start)+"ms");return;}window.scrollTo(0,i*5);setTimeout(f,10);}f();})()) I get about 3800ms on my machine. Safari 5 is about 1600ms. How about you?

Scrolling the page, we have to repaint the entire page on every frame to get subpixel-AA text composited correctly onto the fixed background. Profiling shows 95% of the time under nsLayoutUtils::PaintFrame. 89.2% is under FrameLayerBuilder::DrawThebesLayer drawing content into the layer. 12.4% is under nsTextFrame::DrawText drawing text, but 72.9% is under nsTextFrame::PaintOneShadow drawing text shadows!

If I disable the text-shadow rule, then Safari 5 is about 900ms and we're about 1050ms. So their text-shadows are about 4x faster than ours and that accounts for most of the difference here. One thing I notice is that they turn off subpixel AA when drawing with shadows, but we don't. I don't know why they would do that, it shouldn't make a performance difference.

There are a number of things we can do to speed up text-shadow, but I don't think the current performance is a regression from, say, before retained-layers landed, so I don't think we're going to want to invest in text-shadow blur optimizations for Firefox 4. (Although if we get retained GL layers with component alpha, that would win big here because we wouldn't have to repaint the entire window on every scroll operation.)

(In reply to comment #1) > Can you load that page and try this bookmarklet? > javascript:void((function(){var%20i=0;var%20start=Date.now();function%20f(){if(++i==50){alert((Date.now()-start)+"ms");return;}window.scrollTo(0,i*5);setTimeout(f,10);}f();})()) > > I get about 3800ms on my machine. Safari 5 is about 1600ms. How about you? 6237ms on my 10.5 MacBook. Nominating for blocking because it feels very slow, but I trust Roc to make the assessment about whether fixing it is reasonable in an FF4 timeframe. If GL is supposed to fix this, maybe it's a freebie?

Fwiw, on my 10.6 mbp I see about 2038 using that bookmarklet. It's between 900 and 1300 when I turn on GL accelerated layers. Safari is at 1700.

Whatever other problems GL might cause, I confirm that it fixes the hell out of this. Scrolling is flawless, and the bookmarklet gets me 663ms on the same system that reported 6237ms before.

I'm inclined to say that this isn't a blocker (both since it's appears to be fixed on platforms with accelerated layers (or at least Mac), and it doesn't appear to be a regression).

(For the record, I get 8258ms on a Linux debug build but 2578ms on today's Linux nightly. Though the number varies substantially with window height.)

It's only fixed with GL because with GL we turn off subpixel-AA for the scrolled text. To get subpixel-AA with the scrolled text *and* be fast, we need component-alpha for GL --- bug 593733.