Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040510 The text animation at the above URL is very slow on Windows (but not on Linux). Notice that the "Welcome to Harper House!" text slides across the window from right to left, goes past the left margin, and the slides back again to align correctly with the rest of the main text. As it reaches the end of its animation, the text animation slows down a lot, and takes a long time to complete.

If it's not XP, this is the wrong component (Windows-only means windows event loop or something....) That said, I see slowdown toward the end on Linux -- the text overshoots a bit and comes back. I was assuming that was by design, though... (can't check with IE, and the script filters out other browsers, so I dunno for sure).

(In reply to comment #1) > If it's not XP, this is the wrong component (Windows-only means windows event > loop or something....) Well, it was slower on Linux too when compared with IE, but the speed was basically in the same region. On Windows though, it was much much slower. > That said, I see slowdown toward the end on Linux -- the text overshoots a bit > and comes back. I was assuming that was by design, though... (can't check with > IE, and the script filters out other browsers, so I dunno for sure). The overshooting of the text is by design. It overshoots and then goes back again to align with the other text. Please excuse the lousy coding, this was from back in 2001 before I discovered standards-compliance. :)

Yeah, I'm more or less seeing this too on a trunk build from the 6th, Windows XP. The initial right-to-left movement seems to be at the same speed as IE; the left-to-right movement is slower than the right-to-left movement in both browsers, but is also slower in Mozilla than in IE.

This testcase is better. I think the testcase is pretyy much self explainable. You should probably have a monitor of 1024*768 or higher to get good test results. My results: 1- 2584ms 2- 3225ms 3- 4026ms

I'm confirming this. It seems like Mozilla is repainting/reflowing the scaled image (which is cpu intensive) depending on where the relative div is positioned.

Ok, I've used the testcase to compare with older Mozilla builds, might be interesting: Moz version 1.0 1.1 1.2 1.3 1.7 2005-03-04 2005-03-06 1 - result: 1893ms 1903ms 2673ms 2714ms 2674ms 2533ms 2554ms 2 - result: 2223ms 2674ms 3185ms 3164ms 3135ms 3035ms 3155ms 3 - result: 1262ms 1232ms 1733ms 4006ms 3005ms 3025ms 3966ms The slight regression seen in 3. between 2005-03-04 and 2005-03-06 might have something to do with the fix for bug 284716 (which is windows only).

5 years later... Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4 WIN XP SP3 ChromePlus 1.3.8.2 (Chromium 5.0.356.2) - http://www.chromeplus.org Opera 10.51.3315 Opera/9.80 (Windows NT 5.1; U; en) Presto/2.5.22 Version/10.51 Browser: Fx 3.6.4 ChromePlus Opera 10.51 1 - result: 1580ms 1649ms 1719ms 2 - result: 1594ms 1651ms 1726ms 3 - result: 2120ms 1080ms 1433ms

The url is working fine in performance in Firefox11b, but on trunk it's still rather slow. I think this is related to the other testcases/urls I posted in bug 729597. I've made a testcase that is rather slow now in current Firefox builds, but is quick in Google Chrome. Google Chrome results: 1 - 1569ms 2 - 1560ms 3 - 1042ms Firefox11b: 1 - 11566ms 2 - 11101ms 3 - 14280ms Firefox trunk: 1 - 5064ms 2 - 7161ms 3 - 11436ms Intermittenly, run 1 is rather quick (but not really smooth). With the "Show paint events" link, you can see the paint events occuring (you have to have dom.send_after_paint_to_content=true in about:config). With run 3, you see that the whole document is repainted, so that is probably the reason why it's the slowest path.

Removing URL as it's no longer valid and a few testcases have since been added.