JS animation degrades as more elements are animated

RESOLVED WORKSFORME

Status

()

Core
Layout
P4
critical
RESOLVED WORKSFORME
19 years ago
4 years ago

People

(Reporter: Shashi Narain, Assigned: Chris Waterson)

Tracking

(Blocks: 1 bug, {perf, testcase})

Trunk
Future
perf, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DHTML perf] [nsbeta2-] [nsbeta3-] shashi@narain.com, URL)

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: troy → vidur

Comment 1

19 years ago
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
(Reporter)

Comment 2

19 years ago
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

19 years ago
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

19 years ago
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

Updated

19 years ago
Whiteboard: [MAKINGTEST] astrotech@earthlink.net

Updated

19 years ago
Whiteboard: [MAKINGTEST] astrotech@earthlink.net

Updated

19 years ago
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
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.
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 6

19 years ago
I tried the site using the Sept. 12 build on Linux and can verify what
shaver@mozilla.org 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.
Links not working is a separate bug, and you should file another one.  Please
mark this bug as a dependent of your new bug.

Updated

19 years ago
Resolution: WORKSFORME → ---

Comment 8

19 years ago
Clearing WorksForMe due to reopen.

Please split this bug into two.
Crashes are all M11/P1/critical.

Updated

19 years ago
Whiteboard: [MAKINGTEST] keith@maxwell63.freeserve.co.uk
(Reporter)

Updated

19 years ago
Whiteboard: [MAKINGTEST] keith@maxwell63.freeserve.co.uk → [TESTCASE] shashi@narain.com
(Reporter)

Comment 10

19 years ago
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.
(Reporter)

Updated

19 years ago
Depends on: 14277
(Reporter)

Comment 11

19 years ago
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.
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?
(Reporter)

Comment 13

19 years ago
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.
Assignee: vidur → shaver
Status: REOPENED → NEW
OK.  I have significant experience working with the JavaScript engine, so I'll
take a look at this one today.

Updated

19 years ago
Target Milestone: M11 → M12

Comment 15

19 years ago
m12

Comment 16

18 years ago
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
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.
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.

Updated

18 years ago
Keywords: perf
Summary: [perf] JS animations unreasonably slow → JS animations unreasonably slow

Comment 19

18 years ago
Moving "perf" to keyword field.  This is the are we use now :-)
Depends on: 21879, 22979
Target Milestone: M13 → M14
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.)
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Comment 22

18 years ago
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.
(Reporter)

Comment 23

18 years ago
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.
(Reporter)

Comment 24

18 years ago
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???
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?)
(Assignee)

Comment 26

18 years ago
pav wants it.
Assignee: shaver → pavlov
Status: ASSIGNED → NEW

Comment 27

18 years ago
I have managed to speed this up a bit.  Stay tuned as there is more to come.
Status: NEW → ASSIGNED

Updated

18 years ago
Depends on: 26502
(Reporter)

Comment 28

18 years ago
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???
OS: Windows 98 → All

Comment 29

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

Comment 30

18 years ago
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?
(Reporter)

Comment 31

18 years ago
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.

Updated

18 years ago
Target Milestone: M14 → M16

Comment 32

18 years ago
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17

Comment 33

18 years ago
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?
Keywords: nsbeta2

Updated

18 years ago
Whiteboard: [TESTCASE] shashi@narain.com → [nsbeta2+] 6/1 [TESTCASE] shashi@narain.com

Comment 34

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

Updated

18 years ago
Blocks: 40158

Comment 35

18 years ago
Mass moving all dated nsbeta2+ bugs to M19
Target Milestone: M17 → M19

Comment 36

18 years ago
Updating from [6/1] to [6/15]
Whiteboard: [nsbeta2+] 6/1 [TESTCASE] shashi@narain.com → [nsbeta2+][6/15] [TESTCASE] shashi@narain.com

Comment 37

18 years ago
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.
Whiteboard: [nsbeta2+][6/15] [TESTCASE] shashi@narain.com → [nsbeta2-] [TESTCASE] shashi@narain.com

Updated

18 years ago
No longer depends on: 26502

Updated

18 years ago
Depends on: 43789

Comment 38

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

Comment 39

18 years ago
nsbeta3+
Whiteboard: [nsbeta2-] [TESTCASE] shashi@narain.com → [nsbeta2-] [nsbeta3+][TESTCASE] shashi@narain.com

Comment 40

18 years ago
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?
(Reporter)

Comment 41

18 years ago
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...
Summary: JS animations unreasonably slow → DHTML performance is poor and inconsistent
(Assignee)

Comment 42

18 years ago
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.
Assignee: pavlov → waterson
Status: ASSIGNED → NEW
Keywords: testcase
Summary: DHTML performance is poor and inconsistent → JS animation degrades as more elements are animated
Whiteboard: [nsbeta2-] [nsbeta3+][TESTCASE] shashi@narain.com → [nsbeta2-] [nsbeta3+] shashi@narain.com
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Priority: P1 → P4
(Assignee)

Comment 43

18 years ago
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.
Whiteboard: [nsbeta2-] [nsbeta3+] shashi@narain.com → [nsbeta2-] [nsbeta3-] shashi@narain.com
Target Milestone: M19 → Future

Updated

17 years ago
Blocks: 21762

Comment 44

17 years ago
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.
Keywords: mozilla0.9.2
Hardware: PC → All

Comment 45

17 years ago
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.
(Reporter)

Comment 46

17 years ago
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

17 years ago
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 :) ?
(Reporter)

Comment 48

17 years ago
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...
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago17 years ago
Resolution: --- → WONTFIX

Comment 49

17 years ago
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 50

17 years ago
Sigh.
Status: REOPENED → ASSIGNED

Updated

17 years ago
No longer blocks: 40158

Updated

17 years ago
Keywords: mozilla0.9.2

Comment 51

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

Comment 52

16 years ago
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

16 years ago
Testcase is the URL of the bug.
Created attachment 60382 [details]
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.
Changing each occurrence of

  }
  if (start == 710) {

in the original testcase to

  } else {

fixes the CPU pegging.
Created attachment 60385 [details]
original testcase with "} if (start == 710) {" changed to "} else {"
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.
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).
It's probably still worth filing bugs on the bigger issues within this profile.

Comment 61

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

Keywords: topperf

Updated

16 years ago
Keywords: mozilla1.0.1
Whiteboard: [nsbeta2-] [nsbeta3-] shashi@narain.com → [DHTML perf] [nsbeta2-] [nsbeta3-] shashi@narain.com

Updated

16 years ago
Keywords: mozilla1.0.1 → mozilla1.1

Comment 62

16 years ago
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

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

Comment 64

15 years ago
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.
Keywords: mozilla1.1, topperf → mozilla1.3

Comment 65

15 years ago
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

15 years ago
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

14 years ago
(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...
If you move the window offscreen, how much faster does everything get?
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

14 years ago
Can anyone test whether the performance becomes better with setting
-- snip --
user_pref("viewmanager.do_doublebuffering", false);
-- snip --
in prefs.js ?
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? 
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
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.