Compare these two pages: http://www.formula-one.nu/mozilla/pinballtest/pinball2textAlignLeft.htm and http://www.formula-one.nu/mozilla/pinballtest/pinball2textAlignCenter.htm Let the ball bounce and watch how it moves when it falls down to the floor. In the second page the ball behave very strange when it is below the "bumpers". The only difference between the two pages is the text-align in the small box below the "bounce area". In the first page the small box has the style text-align: left; and in the second page it has the style text-align: center; Maybe we can optimize this in bug 129115 ?

Changing QA Contact

I see no difference in performance between the two pages. Nor do I understand how the summary of the bug relates to the report. If there has been some deeper analysis on how `deciding which lines to dirty needs optimization', I'd love to see that reported. If this is an issue with respect to the correctness of some computations that are going on (i.e., the only complaint I see is `In the second page the ball behave very strange when it is below the "bumpers".'), could we please re-summarize the bug and provide a more minimal testcase? Thanks.

The ball moves a bit smoother in the first testcase. In the second testcase the ball doesn't move as fast as in the first, but when it is below the bumpers it sometimes speeds up to a very high speed. This never happens in the first testcase. I'm using Win 2k. I know people who didn't see this in Linux. I hope I'll have some time next week to minimize the testcase..

I've now reduced the testcase a bit. The URL's are: http://www.formula-one.nu/mozilla/pinballtest/ballMove_alignCenter.htm http://www.formula-one.nu/mozilla/pinballtest/ballMove_alignLeft.htm The only difference between the testcases is that a text is text-align:center in one and text-align:left in the other. The text-align:center case gives strange times between the moves. (Especially when the ball moves below the image to the left.) My testresults: (Win XP, Moz1.1b, PII, 450Mhz) text-align: center; 30 50 40 30 50 30 50 50 40 40 30 40 41 30 40 30 30 40 30 30 30 30 30 40 30 20 30 30 30 20 20 30 20 30 20 20 20 21 20 20 20 20 20 0 10 0 10 10 0 10 0 20 0 10 0 10 0 10 0 10 10 0 10 0 10 10 0 10 10 0 10 10 0 10 text-align: left; 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 21 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

exactle the same here on the two testcases. trunk build 2002072514 on win-xp pro,1.1ghz,512ram

Linux 7.1, remote display on fast switched net. With a fresh trunk build, I see various behaviors. The first several times I tried, both versions produced 20's except for the occasional hiccup(*). I went and did some other stuff, and went back to it 20 minutes later, and tried again. Now the center-aligned one _tends_ to oscillate between 3 and 37, and the left-aligned one has a few periods of oscillation but gets mostly 20's. And after I wrote that, I tried again, and now it's back to the first behavior. This tells me that there are other issues here. One thing in particular I note is that the dynamic-timer-stuff seems to be causing sequences like this: 20 20 20 27 3 20 20 or 20 20 3 27 20 20 or 20 20 3 37 3 37 3 37 etc

hm - I always get the same results (as reported in comment #5) no matter if I just booted the machine of have it some hours/days running. also no difference when other applications are in the background. (this is on win-xp pro).

this is the sort of sequence I see: 20 30 20 20 4 26 30 4 26 30 20 20 4 26 30 4 26 30 4 26 30 4 26 Note that this is linux, and timer code is different on linux and Win32. Definitely an oscillation, however.

Probably the feedback scale factor of 1.5 at line 171 of xpcom/threads/TimerThread.cpp is too high. /be

the two testcases are now at http://www.world-direct.com/mozilla/dhtml/funo/pinballtest/pinball2textAlignLeft.htm http://www.world-direct.com/mozilla/dhtml/funo/pinballtest/pinball2textAlignCenter.htm

Can someone try Brendan's suggestion in comment #9 ?

Anyone willing to take this?

I did do some looking at it with brendan; probably not enough to be sure either way. Changing it wasn't an bvious win for me, but the test env wasn't the best.

nsbeta1- based on comment #13

.

dbaron, is that something that might be covered by your arch rewrite stuff - bug 184746 ?

I have no idea what this bug is about. It should probably be marked invalid and a new bug opened on any remaining valid issues. If I ever implement what I described in bug 184746 comment 11, there will probably be no such thing as "deciding which lines to dirty".

Comparing this to MSIE makes Mozilla appear in a bad light - the whole animation (with 1 ball or with more - by clicking several times on the "start" link) is very choppy.

Trying with latest trunk 2004101904 on winxp pro sp1 the testcases in comment #19 and comment #20 are still extremely choppy. Could anyone do a profile which would provide more insight.

Using trunk build 2005060906 on winxp pro sp2 I still see this, and testcase in comment #19 is slower than testcase in comment #20 - so this bug is still valid.

The two testcases behave very similarly from what I can see here (0% cpu usage most of the time, with short freezeups every so often, presumably for GC). If people want me to look into this, I'll need a testcase that clearly shows a problem.

WFM on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0. Both testcases work the same (also same as Chrome). The images are not rendered but the corrupted file images are moving in their place.