243312 - Text animation is very slow

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Ali Ebrahim]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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).

Comment 2

[Ali Ebrahim]

(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. :)

Comment 3

[Christopher Hoess (gone)]

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.

Comment 4

[Martijn Wargers (dead)]

Attachment: img for testcase

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase

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

Comment 7

[Martijn Wargers (dead)]

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. 

Comment 8

[Martijn Wargers (dead)]

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).

Comment 9

[Carlos Alén Silva]

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

Comment 10

[Martijn Wargers (dead)]

Attachment: testcase2

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.

Comment 11

[Ali Ebrahim]

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