Filed as a Unix-only followup to bug 203439. It looks like nsBlender::Blend()'s attempt to lock the drawing surface forces a gdk_image_get(), which is what takes up almost all the time on this testcase. I don't know whether using Cairo will help here or not, but scrolling is pretty painfully slow in current trunk builds...

Here's another test case which really exaggerates the problem (or possibly a related one): http://devrandom.com/test/firefox/slowfixedscroll.html

Well that's weird, it seems to only scroll really slowly when I have the page that I made the test case from open (in another tab or window): http://www.markboulton.co.uk

(In reply to comment #1) > Here's another test case which really exaggerates the problem (or possibly a > related one): > > http://devrandom.com/test/firefox/slowfixedscroll.html this also scrolls slowly in windows. odd "braking" behavior when these get near the top and bottom (but more noticable with these two) http://www.markboulton.co.uk/ http://gamma.nic.fi/~tapio18/Opetus/index2.php3

> this also scrolls slowly in windows. Anything you see on Windows is not this bug. This bug is about a specific Linux-only issue found by profiling. Note that if you're testing on trunk you should keep in mind that fixed-position stuff is generally slow on trunk right now; there's an existing bug on that. But it's not _this_ bug. vlad, how does cairo handle this testcase?

It seems to scroll fine, even over a remote X connection talking to a cygwin X server. However, there is some sort of problem at the very top of the page, where rendering just freezes until you scroll down a little ways; not sure what the problem is there (I don't think it's related).

Well, I scrolled around a bit in a current trunk optimized cairo build. I see a lot of painting and such in the profile and things are very laggy. Not sure whether it's better or worse than the non-cairo build... vlad, note that fixed-pos stuff was broken in the build you tested, so you might want to retest a current build.