12761 - JS animation degrades as more elements are animated

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P4)

Description

[Shashi Narain]

M9 Build
--------

The initial page loading, Dynamic Animation, and Transitions work correctly but
when you click any of the "user-interface" icons problems appears. The debugger
console says that the JS functions are not defined when if fact they have been.
A few seconds after clicking any of the icons, Mozilla completely freezes and
then crashes.

08-26-17 Build
--------------

The initial page loading, Dynamic Animation, and Transitions work correctly but
the moment you click any of the icons the page disappears from the screen and a
few seconds later Mozilla crashes (raptorhtml.dll goes down).

I wrote in to the layout newsgroup soliciting verfication that what I was
experiencing was not a localized problem. Other Mozilla users have reported back
to me that the crashes are indeed widespread, not just me.

As time allows, I will break down the HTML code I have used on the page to find
what is exactly causing the crashes. For now I remain "clueless" as to why
Mozilla is not working with this page.

Comment 1

[troy]

With today's tree nothing is displayed and the following error is displayed in
the console: "JavaScript error: MoveGeckoIcon is not defined"

Vidur, I don't think this is you, of course, but may know of the problem and who
to assign it to

If once it displays again the reported problem still exists, please reassign
back to me

Comment 2

[Shashi Narain]

As I had origianlly reported, with the M9 and 08-26-17 builds the page loads up
fine. It's what happens *after* the page displays that is causing problems. Troy
has now reported that with the 08-29 build, the page doesn't even display at
all. The MoveGeckoIcon function is the very first JS that kicks in when the page
comes up. It is the beginning of a set of functions that perform the intial
DHTML.

The initial DHTML was working fine in the two builds that I used so it seems
that the problem has gotten progressively worse to the extent that now the page
doesn't work at all.

Comment 3

[Alan S. Jones]

With the 1999083010 build I can load up the main page fine, but then if I click
on the Mona Lisa Icon it seems to load a blank page.  This page seem to act like
it is "stuck".  If I click on reload the page reloads blank and the reload
button disappears.  Shortly after that I get the following:



APPRUNNER caused an invalid page fault in
module KERNEL32.DLL at 014f:bff858cd.
Registers:
EAX=c0016f74 CS=014f EIP=bff858cd EFLGS=00010202
EBX=0063fe28 SS=0157 ESP=0053ffa8 EBP=00540018
ECX=81672cbc DS=0157 ESI=816544b8 FS=13b7
EDX=c0016f78 ES=0157 EDI=81672d00 GS=0000
Bytes at CS:EIP:
53 56 89 4d f8 57 8b 41 40 8b 75 08 89 45 ec 83
Stack dump:

[and yes I tested twice between system reboots and both times the Stack dump
section is empty]

Comment 4

[Alan S. Jones]

Ooops I forgot to add this was in the console window and it might be helpful:

Document http://www.mozilla.org/ loaded successfully
Document: Done (9.06 secs)
FindShortcut: in='http://www.narain.com/gecko/'  out='null'
Document http://www.narain.com/gecko/ loaded successfully
Document: Done (23.73 secs)
JavaScript error: OpenStyleTableIcon1 is not defined

Going to reload
JavaScript error: OpenStyleTableIcon1 is not defined

Comment 5

[Mike Shaver (:shaver emeritus)]

I don't get a crash with a build from Sept14's tree closure on Linux, but I
can't click on links either.  If you can reproduce this, please reopen, and
perhaps reassign to someone else (troy?).  I'm getting it off vidur's list for
now.

Comment 6

[Shashi Narain]

I tried the site using the Sept. 12 build on Linux and can verify what
[e-mail] is experiencing. The site does not crash Mozilla but the
links are no longer working.

I will download and compile for Win32 when the nightly source gets released
later today and report on what I am seeing on the Windows side. I have some idea
on where the problem is eminating from and will add comments to this bug once I
get something more concrete.

I have also re-opened this bug.

Comment 7

[Mike Shaver (:shaver emeritus)]

Links not working is a separate bug, and you should file another one.  Please
mark this bug as a dependent of your new bug.

Comment 8

[leger]

Clearing WorksForMe due to reopen.

Please split this bug into two.

Comment 9

[Mike Shaver (:shaver emeritus)]

Crashes are all M11/P1/critical.

Comment 10

[Shashi Narain]

The following comments are based on the 09-17-08-M11 build for Linux and Win32.

LINUX:

Crashes no longer occur but a new problem has surfaced. When the first icon
reaches about the 1/3 mark across the screen, it stops dead on its track. A
quick look at my CPU meter shows a 100% load (I have a P3-450 system). After
about 5-10 seconds, all the icons appear at their final position (no movement
happens). After another 5-10 seconds, the text appears but without the
pseudo-transition DHTML that I have coded.

WIN32:

Crashes no longer occur. The new problem described above is not evident in the
Win32 builds. The loading and intial DHTML of the page work fine under Win32.

As for the linking...I have found the problem and will be opening a new bug in
the next few minutes. For those of you interested in the link bug, I will be
addintg a comment here with the bug number.

Comment 11

[Shashi Narain]

The links bug is rather nasty (causes crashes under Win32). I have opened a new
bug for this...#14277. I have marked this bug as a dependent of the new one.

Comment 12

[Mike Shaver (:shaver emeritus)]

OK, I see the behaviour you're talking about on Linux with the DHTML slide-in of
the icons, but there's _way_ too much going on on that page for me to really
debug it.  Can you try to reduce this to a minimal case and attach it here?

Comment 13

[Shashi Narain]

Vidur and I had discussed this "new" problem back in July when I first
experienced it in Windows98. Now the problem is showing its face on the Linux
side. Both of us agreed that the code I used was choking something within the
JavaScript Engine.

I designed an exhibit, aptly named JavaScript Stress Test, within the Gecko's
Realm to make sure that this type of choking gets eliminated. You can find the
test at http://www.narain.com/gecko/bugs/js-stress-test.html

The only thing this test does is to slide-in all of the icons. When you view
this test you will see that the first two icons slide-in very smoothly. The last
four icons show no movement...they simply appear after the JS Engine unchokes
itself.

Comment 14

[Mike Shaver (:shaver emeritus)]

OK.  I have significant experience working with the JavaScript engine, so I'll
take a look at this one today.

Comment 15

[chris hofmann]

m12

Comment 16

[Jacob Kjome]

The same sort of slowdown happens in IE5, except not as pronounced, but you can
see that after the first 2 smoothly move over to the right, the rest get slower
and slower as they come in.  Not sure if that gives any new clues as to why
this is happening, but...  It certainly is MUCH worse in gecko.  I'm using
1999111808 win32 build on Win2000 RC2

Jake

Comment 17

[Mike Shaver (:shaver emeritus)]

I think we're going to need quantify data for this, because I'm having a hard
time tracking it down with just GDB.  Putting on the perf radar, spamming
waterson for guidance and updating summary.  Also, not for M12 unless we get a
good handle on the root cause pretty soon.  Sorry.

Comment 18

[Mike Shaver (:shaver emeritus)]

I think we're going to need quantify data for this, because I'm having a hard
time tracking it down with just GDB.  Putting on the perf radar, spamming
waterson for guidance and updating summary.  Also, not for M12 unless we get a
good handle on the root cause pretty soon.  Sorry.

Comment 19

[leger]

Moving "perf" to keyword field.  This is the are we use now :-)

Comment 20

[Mike Shaver (:shaver emeritus)]

I'm interested in what happens to this bug when 21879 and 22979 are dealt with.
(The latter is the most interesting to me: you might try applying the patch in
bug 22979 and rebuilding on Windows.)

Comment 21

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 22

[chrisn]

I have tested this in the 2000012208 build on Windows 98. Michael Lowe tested 
the same build on WinNT4.

The behavior of this page in the latest build is much improved over what 
previous comments have stated, possibly due to michael lowe's new timer code - 
bug #22979. However, there is a caveat.

Visit the page listed in the URL field for this bug. Initially, 5 sliding boxes 
appear from off the left of the screen, and move towards the right and their 
resting place about 2/3 of the way across the screen. On Win98, when the first 
box appears, it moves slowly. As soon as the second box appears on the screen, 
both boxes speed up, and the faster pace of the boxes is maintained as the rest 
of the boxes start their slide across the screen. When the first 4 boxes are in 
their resting place, and there is only the final box left moving, it slows down 
to the original pace of the first box.

Now, what's even weirder is that Michael Lowe doesn't experience that behavior 
on NT4. Instead, as more boxes appear on the screen, the pace of their movement 
_slows down_. As the boxes reach their destination one by one, the pace picks up 
again. Almost opposite what I'm experiencing on Win98.

I have no idea what couold be causing the discrepancy. However, I can say that I 
can not duplicate the behavior mentioned in previous comments. Also, I can state 
unequivocally that, in regards to rendering this page, Mozilla is a racehorse 
compared to IE5.0. Thought you might like to hear that.

Comment 23

[Shashi Narain]

When I opened this bug back in August it was regarding a problem totally 
different from what it is now (somehow it metamorphosized along the way). At the 
present time, this bug strictly deals with the performance of JS animations. My 
apologies for the confusion caused :-)

Now to the problem at hand...I d/l'ed a copy of the 01-22-08 build and can 
verify what Chris is experiencing within Win98. The differing in speed of the 
icons should not be happening (if any of you have IE5 installed...check out the 
page and you will see that the icons all move at the same speed). Here is a 
snippet of the JS code I used in the page that may help illuminate the problem.

function MoveGeckoIcon(start, finish, step, speed){       
   if (start < finish){      	   
    document.getElementById("geckoIcon").style.left = start+"px";  
    start=start+step; 
    setTimeout("MoveGeckoIcon("+start+","+finish+","+step+","+speed+")",speed);
   }
   if (start == 235) {
	 MoveWelcomeIcon(-65,710,10,5);
   }      
}

As you can see, it is a fairly simple function that repeats itself until certain 
conditions are met. Of key interest to this bug are the "step" and "speed" 
variables. All icon movements have these variables set to 10px and 5ms 
respectively thus producing a smooth animation across the screen. The fact that 
the icons are still moving at differing rates tells me that something is still 
not quite right.

Also of interest is the CPU usage during the animation. When this page is viewed 
on my P3-450 box with IE5, the animation sequence uses ~10-13% of my CPU. With 
Mozilla, the usage shoots up to 100% (exactly the same as I commented on 09-19). 

Just to throw a little weirdness into the pot...after the animation sequence is 
complete, the page performs a series of pseudo-transitions. These transitions 
are completely driven by JS and the functions involved are structured *exactly* 
the same as the snippet from above...the only difference is that instead of the 
CSS left: property being manipulated it is the CSS clip: property. If all this 
has to do with the timing code within Mozilla, shouldn't there also be a 
diference in the speed of the transitions??? If you click the various icons on 
the page, you will see that the transitions all move at the same speed 
(fyi...the step and speed for the transitions are a uniform 5px and 1ms 
respectively).

One last note...these comments are based on Win98. I will give this bug a test 
run using the same build for my Linux box. I am interested in seeing what is 
happening on that side.

Comment 24

[Shashi Narain]

I just took a look at the page using the 01-22-09-M14 build for Linux and here
are my comments...

When the icons begin moving across the screen, it is not a smooth animation but
rather a *very,very* choppy movement. During the entire animation sequence, the
CPU usage was at 100%

Even scarier is what happens during the pseudo-transitions I mentioned in my
last comment. The speed of these transitions are down to a crawl...it is taking
an extraordinary long time for the "section windows" to open and close. As with
the animation sequence, the CPU usage during the transitions is 100%

A side note...this bug has been assigned to Mike Shaver who is no longer
involved with Netscape. Should this bug be re-assigned to someone else???

Comment 25

[Mike Shaver (:shaver emeritus)]

Well, damn.  I had such high hopes for michael.lowe's timer joy.  Oh well.

I'm getting Quantify data on this now, maybe I'll find something juicy.

(What does being employed by Netscape have to do with anything?)

Comment 26

[Chris Waterson]

pav wants it.

Comment 27

[Stuart Parmenter]

I have managed to speed this up a bit.  Stay tuned as there is more to come.

Comment 28

[Shashi Narain]

These comments are based on the 02-03-08-M14 build for Linux...

I have an exhibit in the Gecko's Realm that you might want to take a look at.
Because of bug #11333 you can't access the page via a link so you will need to
input the URL manually. The URL is
http://www.narain.com/gecko/dhtml/transitions.html

This exhibit goes through all the ten pseudo-transitions that can be done by
manipulating the CSS clip: property. The code used on this page is *identical*
to that in the main page...but the performance is vastly different. In this
exhibit the pseudo-transitions are going alot faster than it is supposed to.
Also, if you look very closly, at certain points it speeds up and then slows
down.

The question that begs to be asked is this...why is it that the same code is
causing such a vast difference in speed??? In the main page, the
pseudo-transitions are slow as hell but in the above exhibit it is going faster
than it is supposed to be.

I noticed that Pav has opened a new bug in reponse to this problem (#26502).
This new bug is specifically targeted for Linux but the problem is still not
solved in Win32. How should we deal with this???

Comment 29

[Stuart Parmenter]

ok.  this is *almost* fast enough in an optimized build on my P3 500... still
trying to see what I can do. :-)

Comment 30

[Joe Hewitt]

Has any work been done on this?  As of M14 animation is still really slow on 
Win98 and WinNT.  If this performance lag remains by the time Netscape 6 comes 
out, you will probably never see anybody even attempt to do DHTML in Mozilla.  
What this comes down to is that any changes to CSS properties, particularly 
position, size, or clipping, take a long time to repaint... 

Can't we do better?

Comment 31

[Shashi Narain]

The following comments are based on 03-28-09-M15 (Win98) running on a P3-450, 
128mb ram box.

First the good news...I have noticed a dramatic improvement in DHTML 
performance since I last posted a comment on this bug. The bad news is that 
things are still not quite right.

Here is a detailed picture of what I am seeing on my box:

Icon Animation...the first icon's movement is about right if a tad slow. When 
this icon hits the half-way mark of the browser (800x600) it suddenly shifts 
gear and flys across the screen. The next four icons are also speed freaks and 
zip right through. The last icon also starts out very fast but when it hits the 
half-way mark it slows down to the speed at the beginning of the animation. The 
CPU usage peaked at 60%.

DHTML Transitions...the initial transition of the title banner and first window 
are near perfect. So what's the problem??? Click the various icons in a random 
order one after another. Take a close look at the transitions and you will see 
that they are sometimes fast, sometimes slow, and more bizarely they sometimes 
shift speed during mid-transition. During any close/open cycle, the CPU would 
spike to 100% and then drop back down to 0%

The bottom line is that Mozilla's DHTML performance is horribly inconsistent. I 
coded the animations and transitions to be performed at a specific speed so why 
can't Mozilla adhere to what I tell it to do??? In this regard, Netscape 4.x was 
way more consistent.

One last note...I'm going to give my site a spin on Linux using the latest 
build. I'll post a comment on what I see on that end when I get a chance.

Comment 32

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 33

[Peter Trudelle]

Default start page <http://home.netscape.com/browsers/6/su_setup.html> also 
pegs my PII-366 on Win98. Putting on nsbeta2 radar: do we really want the first 
page loaded to bring the machine to its knees?

Comment 34

[Peter Trudelle]

[nsbeta2+] will take a fix until 6/1

Comment 35

[Peter Trudelle]

Mass moving all dated nsbeta2+ bugs to M19

Comment 36

[leger]

Updating from [6/1] to [6/15]

Comment 37

[Jim Roskind]

Cleaning up status whiteboard by marking beta3 minus (6/15 has passed)

There is a lot of work pending to get beta2 out, so we're probably going to have 
to live with this initial page load slowness for now.

Comment 38

[Peter Trudelle]

Nominating for nsbeta3: today's opt verification build still pegs CPU on Win98,
this will make a strong negative first impression on new users.

Comment 39

[Peter Trudelle]

nsbeta3+

Comment 40

[Stuart Parmenter]

so some of the pages listed in this bug seem pretty snappy (on my dual P3
500...)

but the home.netscape.com one sucks.  but I think that page is just doing stupid
things, so I don't think it can be fixed too much.

http://www.narain.com/gecko/bugs/js-stress-test.html is also pretty slow, you
said you thought it was JS related, so i'm adding brendan to the CC list.

also, on just http://www.narain.com/gecko/, the way timers get fired and handled
when multiple things are on the screen seems a bit odd...  I'm not sure I
understand this either.  Probably due to the time it takes layout to process a
timer.  unsure exactly though.

I don't know how much this bug should really cover.  I'm at the point where I
think this bug can be marked fixed, and new bugs for the other things should be
opened.  What do you guys think?

Comment 41

[Shashi Narain]

These comments are based on MozLinux using source pulled from the tree a few
hours ago and compiled with full optimization (no debug **** :-)

Pav --

>http://www.narain.com/gecko/bugs/js-stress-test.html is also pretty slow, you
>said you thought it was JS related, so i'm adding brendan to the CC list.

As mentioned in a previous comment, I discussed this with Vidur last summer but
we couldn't put our fingers on where the problem was. Running the Stress Test
through my Moz build on a P3-450, I am still experiencing the same issues as I
did a year ago. The first two icons move across the screen quite nicely. The
third, fourth, and fifth icons get progressively choppier until you reach the
sixth icon. This one shows absolutely no animation...just two very large steps.
During the whole routine my CPU is permanently pegged at 100%

>also, on just http://www.narain.com/gecko/, the way timers get fired and
>handled when multiple things are on the screen seems a bit odd...  I'm not sure
>I understand this either.  Probably due to the time it takes layout to process
>a timer.  unsure exactly though.

Running this page through my Moz build, I am happy to say that the animation of
the six icons are relatively smooth (there are still sections of choppiness).
But sadly, Moz is still eating up some major CPU cycles (~70%).

What bothers me is that the DHTML code I used to perform the animations are
identical between the Stress Test and the index.html page but yet we are seeing
such a vast difference in performance. Why should this be???

I have a perfect example to illustrate what is at issue here. After the icons
have finished their animations, a banner will gradually reveal itself. This is
accomplished using DHTML on the clip property. As you can see, Moz deals with it
quite smoothly with very low CPU usage.

After the banner has been fully revealed, a table underneath it goes through the
same DHTML routine. But as you can clearly see, Moz struggles like hell to open
up this table. During this specific routine, the CPU sits at the 100% mark.

Now, compare the performance of those two with
http://www.narain.com/gecko/dhtml/transitions.html In this example, I run the
same DHTML routine but instead of text, it's on an image. The entire demo runs
very nicely although my CPU still hovers around the ~50% mark.

Three different uses of the clip property with three vastly different
performances. This jibes with a comment I posted earlier this year...Moz is
still horribly inconsistent.

>I don't know how much this bug should really cover.

I have to admit that the summary I used when opening this bug wasn't very good.
I think the new summary I have inputted reflects the situation more closely.

>I'm at the point where I think this bug can be marked fixed, and new bugs for
>the other things should be opened.  What do you guys think?

I openend this bug nearly a year ago (yes it's been that long) and we are still
no closer to solving this. Considering the **** performance I am seeing on an
optimized build on a P3 box, I hate to imagine what performance others are
experiencing using the debug builds and/or running it on a machine with less
power.

With all due respects Pav, I will keep this bug open until I am satisfied that
DHTML performance is up to my standards (and these are extremely high :-)

In closing this comment I want to leave you all with two thoughts. When I
created the Gecko's Realm two years ago, my aim was to show-off all that was
wonderful about Mozilla and the Gecko layout engine. I hate to have to say that,
DHTML-wise, IE5 is superior to Mozilla :-(

All the demos currently residing within the Realm are relatively simple. If Moz
has such a hard time dealing with these, what the hell is going to happen when
I, or anyone for that matter, develops something alot more complex. I shudder at
the thought... Those of you who are regular visitors to my site will have
noticed that no new demos have been put up in quite a long while. You now know
why...

Comment 42

[Chris Waterson]

This bug should probably not be assigned to pavlov unless it is specific to X11 
(which, according to the OS/Version, it is not). I'll take it for now, and will 
look into the problem with the flying icons.

shashi: it would be tremendously helpful if you could provide me with a 
minimized test case that has only the "flying icons", as this seems to be the 
primary complaint that this bug relates to. ("My whole website is slow" does not 
count as a testcase!)

Furthermore, if you could isolate the minimal differences between the other 
"horrible inconsistencies", and file new *focused* bugs that illustrate, I 
would very much appreciate it. That would help us to solve these problems, and 
increase the chance that your high standards will be met.

Comment 43

[Chris Waterson]

I spent about an hour examining the test case and it's...creative. It's kicking
off a separate 5ms time out for each animation. This appears to flood a queue
somewhere and stops us from being very responsive. Slowing the timeouts down to
50ms (or 50 of whatever units setTimeout() is expressed using) improved the
situation markedly.

Although I know shashi's response will be, "gee, it should just work", I think
the author could probably improve this by having a single "heartbeat" that
controls all animations.

We're probably not being as efficient as we could be reflowing absolutely
positioned items, but turning paint flashing on showed that at least the repaint
areas are correct (i.e., small).

Roundabout way of saying, I'm not working on this in the next few weeks.
[nsbeta3-], Mfuture. Nisheeth, if you want to tackle this bug in your DHTML
performance crusade, please feel free to take this off my plate.

Comment 44

[James Green]

Coming up to a year following the last comments, I've tested
http://www.narain.com/gecko/ in my optimised tip build from yesterday on Linux.
The initial opening animations are 'okay' but the table wipes are still very
slow and jerky. This testing on a K6-2 300Mhz w/ 256Mb ram.

Reporter: what are your current thoughts on this issue? I'm setting Platform to
All, since this is highly likely to be XP code. Nominating for 0.9.2 to get
updated examination by engineers.

Comment 45

[Alan S. Jones]

James, 

I may be getting my bugs confused, but you mentioned table whipes.  I think the
best sample of table/js whipe issues is on the Bugzilla Query page.
http://bugzilla.mozilla.org/query.cgi

Scroll down to the bottom with the columns Program, Version, Component, and
Target Milestone.  Click on BROWSER in the Program group.  Watch everything come
go extreamly slow.  Any other Mozilla windows that are open are frozen while
those boxes are rerendered.  

Looks really bad for mozilla to mess up on our own bug pages.

Comment 46

[Shashi Narain]

James,

I see the same slow and jerky animations on my P3-450/128mb box (Linux & 
Windows). But then again, I have been experiencing this for quite a long time 
(this bug was filed 21 months ago).

You ask my current thoughts on this issue...if you look at the dates when this 
bug report was opened and when I last posted a comment, it should be clear what 
my thoughts are. Makes me wonder why I am even bothering to type out this 
comment :-)

Comment 47

[James Green]

Alan: the bugzilla query page issue is repopulating a select element using a JS
array, nothing to do with this bug. <ponder type="conspiracy">Although I'm not
able to find the bug on the query page JS being slow right now.</ponder>

Shashi: I feel your pain :(. Nothing I can do about it bar keep an eye on
bugzilla for these issues and continually raise *cough* remind people about
them. I do however see that Chris Waterson has asked about your code,
specifically the way timers are used; perhaps you could take a look and see
whether these could be cause undue performance problems in the best of JS
engines :) ?

Comment 48

[Shashi Narain]

James (and everyone else),

As I have mentioned in previous comments, nothing is wrong with my code. This 
opinion is founded on three points.

1) Take a look at the site using IE5. The animations are near flawless. If IE 
can render my code, why shouldn't Mozilla?

2) Take a look at http://www.narain.com/gallery/ using NN4.x The JS animations 
should look very familiar. The code I used in my Gecko site was recycled from 
this site. If NN4 can do these animations, why shouldn't Mozilla?

3) During the preview release phase of NN6, the end-user was taken to a 
"start-up" page the first time they used the browser. This page contained JS 
animations which were exhibiting the same problems (slow, jerky, 100% cpu, etc.) 
but using different code. As you can guess, Netscape pulled the page when NN6 
was officially released since it would expose a major weakness.

I first brought up the issue of DHTML performance in early-1999. It is now two 
and half years and 20-odd milestone builds later and there has been no 
improvement in performance. I have changed the bug status to "WONTFIX" since it 
is quite obvious this issue will not get resolved anytime in the near future.

Note to anyone wishing to re-open this bug: Do so only on the condition that it 
will be fixed. No point wasting everyone's time...

Comment 49

[James Green]

You don't WONTFIX just because you're annoyed that a bug isn't being looked at.
Leave it open and eventually someone will come along and say "hey, this no
longer affects us" or "here's a patch" or similar. Reopening.

Whether Shashi is using 'slow-by-design' code or not, if IE/Nav4.x does it
quicker, then we're doing it wrong, thus it's a bug.

I have to wonder whether hyatt's style changes are going to have any bearing on
this; both changes are likely to be in the 0.9.2 release, so it might not be
immediately testable in nightlies.

Comment 50

[Chris Waterson]

Sigh.

Comment 51

[basic]

This seems to look real good on build 2001102903 win32 for me

Comment 52

[tradervik]

Tested on PIII 450Mhz with 384 Mb RAM and Mandrake 8.0 using 20011012 build. The
URL http://www.narain.com/gecko/ rendered okay with decent speed but was very
CPU intensive. The stress test URL,
http://www.narain.com/gecko/bugs/js-stress-test.html, was also very CPU
intensive and the animation became a bit slow with the sixth (last) flying graphic.

Comment 53

[Jason Kersey]

Testcase is the URL of the bug.

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: variant of testcase that doesn't peg CPU

I decided to rewrite the JS to see if writing it differently wouldn't peg the
CPU.  It didn't.  So now if we can figure out the key difference between this
testcase and the original one we might be able to figure out what the problem
is.

Comment 55

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Changing each occurrence of

  }
  if (start == 710) {

in the original testcase to

  } else {

fixes the CPU pegging.

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: original testcase with "} if (start == 710) {" changed to "} else {"

Comment 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Doh!  I see the basic problem -- the animation algorithm is O(N^2).

Consider the following.  We get to the call to MoveGeckoIcon(705, 710, 5, 5). 
start is less than finish, so we set start to 710 (start + step), and set a
timeout for MoveGeckoIcon(710, 710, 5, 5).  Then we see that start is 710, and
call MoveWelcomeIcon(-65, 710, 5, 5), which sets a timeout for
MoveWelcomeIcon(-60, 710, 5, 5).  So now we have two timeouts for 5ms later, in
the order:

MoveGeckoIcon(710, 710, 5, 5)
MoveWelcomeIcon(-60, 710, 5, 5)

When the first of these gets processed, start < finish is no longer true, but
start == 710, a second time, so we set another timeout for MoveWelcomeIcon(-60,
710, 5, 5).  So now we have two sets of timeouts for MoveWelcomeIcon, 4 sets for
MoveCssIcon, ... up to 32 sets for MoveCreditIcon.  I did notice in my profile
that a surprisingly small amount (under 25%) of the time was actually spent
handling the style changes -- much of it was spent in JS execution.  I guess I'm
wondering how other browsers manage to execute the JS so much faster.

Comment 58

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, and while when we have two sets of timeouts, every other style change won't
amount to anything, since we change to -55, -55, -50, -50, -45, -45, etc., once
we have 4 or more sets of timeouts we will do multiple style changes for each
shift.  So the 25% of the performance time spent handling style changes (and
perhaps the 15% spent in reflow) could probably be improved by batching style
changes, although I'm not sure, since the batching probably wouldn't last across
timeout events anyway (although maybe it could).

Comment 59

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: jprof profile

Comment 60

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It's probably still worth filing bugs on the bigger issues within this profile.

Comment 61

[Markus Hübner]

comment #57 seems to describe what is happening why we are still slow at
bug 104593. (even with 129953 & 129115).

Comment 62

[Stig Nygaard]

Maybe http://www.cross-browser.com/ss/solar_system.html is a good example of the
problem too.

On my PC (AMD K6-II/400MHz, Win98) Mozilla 1.1beta completely freezes when
entering this solar system animation. It was the same problem in 1.0RC2, but it
was solved in RC3 and the final Mozilla 1.0 release. Now its back :-( I have to
kill the browser from the task-list.

Comment 63

[Markus Hübner]

Stig: this is a recent regression.
see bug 153083 and bug 157401

Comment 64

[Markus Hübner]

http://www.narain.com/gecko/bugs/js-stress-test.html
comparing trunk build 2002111908 on win-xp pro,1.1ghz,512ram the animation is 
really choppy - absolutely fine on msie.

Comment 65

[Markus Hübner]

Using the latest trunk build 2003070908 on the same system, still the same as 
mentioned in comment #64
A profile would really help here.

Comment 66

[Wolf550e]

Follow up on <a href="#c64">comment #64</a>:

Using "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
Firebird/0.7", with the testcase, confirm choppy animation and tearing on P3-733
w/ 384MB RAM.

The animation is choppier than in MSIE6SP1, but it's not completely smooth on IE
either - it's slower and choppier, but on IE the high speed animation causes
more tearing.

Comment 67

[Brent Silby]

(In reply to comment #66)
Confirm problem. Runs fine in IE6 on my 2.4GHZ CPU. Runs inconsistently on 
Mozilla build 2004031616. The animation slows to a crawl.

This bug can further be confirmed by viewing my dhtml games. Try, for example 
www.def-logic.com/amenra/index.html on IE6 then compare with Mozilla.

There seem to be a few issues here. The problem is worst when image resizing 
is taking place. It is also significantly worse when the background image is 
complex and transparent gifs are moved across it. In my example at def-logic, 
the problem is reduced when the background image is removed. Perhaps Mozilla 
is repainting the entire background on every cycle...

Comment 68

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If you move the window offscreen, how much faster does everything get?

Comment 69

[Zibi Braniecki [:zbraniecki][:gandalf]]

On my 1.8 Ghz Athlon Linux machine animation stops at the end of pre-last
element movement. After switching tabs and switching back to that tab I see also
last image at the right place.

Konqueror animates this also choppy but without any repainting problem

Comment 70

[Roland Mainz]

Can anyone test whether the performance becomes better with setting
-- snip --
user_pref("viewmanager.do_doublebuffering", false);
-- snip --
in prefs.js ?

Comment 71

[Drew "DanteAliegri" Ogle]

Tested in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060329 Firefox/1.6a1.

The cpu usage doesn't peg like it did in the past, and the animation doesn't seem to substantially degrade like it also did massively in the past. You can tell a difference between the URL version and the "variante of testcase that doesn't peg CPU", but I'm not sure if absolute parity is what is being expected here? 

Comment 72

[Ryan VanderMeulen [:RyanVM]]

No significant difference in CPU utilization between the 3 testcases.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061206 Minefield/3.0a1