Painting http://tinderbox.mozilla.org/Firefox/ has gotten much slower since bug 368247 (border painting rewrite) landed. Doing PgUp/PgDown on tinderbox used to be instantaneous; since that patch landed it has taken about a second. Steps to reproduce: 1. load http://tinderbox.mozilla.org/Firefox/ 2. hit the PgDn key a few times to scroll down by pages Expected results: scrolling down occurs instantaneously Actual results: the very top slice of the page (the overlap, which is blitted instead of repainted) appears instantaneously, but the rest of the page takes about a second to appear. top shows that the X server is using 97%-98% CPU. Works correctly in Linux Firefox nightly 2007-04-30-04-trunk. Broken in Linux Firefox nightly 2007-05-01-04-trunk. Therefore, I'm presuming it's due to bug 368247. I'm using an IBM T42 laptop with an ATI Mobility Radeon 9600 M10 video card; I use the ATI proprietary drivers (xorg-x11-drv-fglrx-8.36.5-1.lvn6 from Livna) on Fedora Core 6, but without the kernel module (kmod-fglrx). I'd have filed this earlier if I hadn't been blaming the slowness on cycle collection pauses.

I see pretty much the same thing on my old laptop: a Dell laptop with an ATI FireGL 9000, running Fedora development (almost Fedora 7 now), with the radeon driver (the free one). Though on the older machine the repaint pause is more than a second. So it's not driver-specific. I've also seen the repaint pauses on articles on the New York Times, and at the bottom of the page on bugzilla.

Setting doSeparateSides to false makes the performance problems go away (although not all of the borders are drawn). Not doing the PushGroup, SetOperator, and PopGroupToSource also makes the performance problems go away, although the drawing problems are even worse that way.

This bug is bad enough that it's making it hard for me to dogfood the trunk -- I don't think it's acceptable to ship an alpha with it.

This turns off antialiasing of borders, which I think we should do until we can get the performance back some other way.

Can we do this on linux only? It doesn't seem to be as much of an issue on win32 and mac, no?

I'm a little scared of doing this in a platform-specific way since I worry it'll end up permanent rather than temporary and we'll end up shipping without feature parity. But here it is. If this lands, I'll file a bug on undoing and nominate it for blocking1.9.

Comment on attachment 265691 [details] [diff] [review] patch to disable antialising of borders Yeah, I agree -- FWIW, I'm looking at this right now on linux to see if I can figure out what the performance issues are.

Well, I checked the above patch into the trunk and filed bug 381735 on reenabling the antialiased border drawing, but it looks like you want to keep using this bug (since you just assigned it to yourself), so not marking fixed.

This -should- be fixed by checked-in patch from bug 368247; dbaron, can you check and resolve this if so?

This seems to be WFM/FIXED now. Any reason to keep this still in 1.9+ list?

Marking fixed.