107746 - DHTML Animations running slow when animated elements are wrapped by a larger-sized container element

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Markus Hübner]

http://www.world-direct.com/mozilla/dhtml/index.html
just click on "company" to start the sliding menu.
The animation takes 1.5 secs on MSIE and 6.5 secs on the
latest mozilla build (2001102903) - using win2k SP2.

the dhtml code is at
http://www.world-direct.com/mozilla/dhtml/slidingmenu.js

Comment 1

[R.K.Aa.]

are the "menus" supposed to do anything but display? They aren't indicated as
links and clicking them does nothing..

Comment 2

[Markus Hübner]

In this testcase they just slide in - nothing more :)
But enough to show the poor DHTML performance.

Comment 3

[Manfred Schneiderbauer]

The test case at the assigned URL was renewed now; i completely re-wrote the 
script to have all animations in only one setTimeout to ensure that the browser 
doesn't have to perform more than one setTimeout at once; further the timeout 
will be cleared after the last movement. This removed certain MSIE5.5 
performance problems, but Mozilla still doesn't do the animation smoothly. I'm 
creating several new arrays in every run and splitting up a parameter string 
into these arrays. Could it be that this affects the performance?
The animation still runs perfectly smooth in NN4, MSIE4, MSIE5.5 and MSIE6.

Would be good to get a profile on this one.

Comment 4

[Markus Hübner]

The complete animation takes about 1sec on msie6 and 11secs with build 
2001110209 on win2k.

Comment 5

[Manfred Schneiderbauer]

Measured Opera too now, it takes about 2 seconds in 5.12.

Sometimes Mozilla uses to not display the graphics after loading the page. When 
this happens, the empty divs (displaying the placeholder graphics' rectangles) 
animate smoothly! My next thought then was that probably the animation would 
run smoothly when replacing the graphics buttons with text. I did so, but the 
text-only version performed equally bad. Could it have to do something with CSS 
properties being not assigned and not to be rendered when the object is "empty" 
but taking up lots of time when the object is "not empty"?

Comment 6

[Manfred Schneiderbauer]

Btw, the same phenomenon appears as well in K-Meleon Version 5 Build 500 
(Win2k).

Comment 7

[Markus Hübner]

as talked with fabian on IRC he believes it's
"nsDOMCSSDeclaration::ParseDeclaration(), other frame-related stuff ..."
but probably also style-resolution is one of the culprits.

Comment 8

[Markus Hübner]

Seems this one is also related to bug 104593 hurting some top100 sites.

Comment 9

[Markus Hübner]

Has there been a change recently?!
Trying with build 2001121703 on win2k there is no "sliding" ... when clicking 
on 'company' the first pixels of the first menu item are displayed, then a long 
break and then the end of the last menu item is being displayed.

Comment 10

[Markus Hübner]

With the great help of Fabian the javascript code has been optimized again.
The new testcase is now available at
http://www.world-direct.com/mozilla/dhtml/index3.html

But still the same phenomenon on my PIII, 500MHZ, 327 RAM, 32MB VCard and using 
build 2001122603: Most of the time there is no animation at all, just the final 
positioned elements are being displayed. This is also seen by other people - 
see last comments in bug 104593. This started just with the checkin of pavlov's 
new timer code.

Though optimized it still takes 6secs on my 1.1GHZ workstation.

Comment 11

[Markus Hübner]

bug 117061 is refering to this problem described!

Comment 12

[Fabian Guisset]

On my computer the animation takes roughly 4000ms to complete. I mesured this
using new Date() at the begining and end of the animation.
When commenting out this line:
document.getElementById(gMenuData[i].name).style.left = gPositions[objectPosition];
which is the only style modification of the code, the animation takes ~1000ms to
complete. The math is easy.

Also for some reason using setInterval is about 200ms faster than using
setTimeout recursively.

Blah. This is not easy.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

See 117061; I have a proposed patch that may help you and fixes your test case
(it seems).

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

I looked at the JS code for this page.

It amounts to a busyloop - it moves the images as fast as the browser can
execute the JS.  The timeout used is "window.setTimeout("moveObjects()", 1);" --
i.e. run moveObjects 1ms (!) in the future.

Since the code generally needs more than 1ms to execute (especially moving the
text), this amounts to a "run this loop as fast as you can", with the added
overhead of going to sleep and immediately waking up.  Probably IE is a) not
going to sleep at all, b) running the specific JS in question faster, or c)
queuing the graphical update to another thread, thus allowing this positioning
loop to run faster -- or some combination of them.

So, no, the patch doesn't really help here.  An auxilliary patch to not go to
sleep if the time is 3ms or less might help, but would have other issues.

Since this is busy-looping JS, I may do a jprof just to see where it's spending
that time; however the real problem here is bad JS animation code.  Those menus
will be dramatically slower on a slower system because of the way the JS is
written, even in IE or NS4 I believe.

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

From a jprof (BTW, it runs MUCH faster on a dual-450 system optimized than on an
800 system compiled debug, no opt):

(Note: all %'s are of the total 200 hits)

50% is spent in f+d ViewportFrame::Reflow()

15% is spent in f+d nsStyleContext::GetStyleData(), called from all over

25% is spent in Refresh (paint) (Note: I was using a remote x display, but this
was not a realtime jprof).
Note that a lot (1/4) of time in Refresh was spent in
nsCSSRendering::PaintBackground(), which spent half it's time in
nsPresContext::LoadImage(), of all things!!!  This may be a real bug.
1/2 of the time in Refresh was spent in nsImageFrame::Paint(), which also seems
odd.

The last 25% of the time was spent in firing timers, and all of that was spent
in GlobalWindowImpl::RunTimeout() -> nsJSContext::EvaluateString(), probably
invoking moveObjects().  7% was spent in setLeft(), 6% in CanAccess(), much of
that in GetPolicy().  3% in js_LookupProperty()

So, given all that, the real blocker seems to be Reflow, followed by refresh. 
CanAccess seems to use way more time that makes sense; I wonder if some form of
caching could help there.  We still need to verify how long setTimeout()
actually sleeps for, but the CPU isn't all going (directly) into running the
timeout callback it appears.

Adding some JS/reflow people.

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

Attachment: jprof dual-450 P3 Linux RH7.1 -O2 --disable-debug

Jprof.	Note: remote X, not real-time.	period = .0015.  fresh pull/build 12/28

Comment 17

[Markus Hübner]

Randell, 
// however the real problem here is bad JS animation code.

Even the JS code, before Fabian did further optimization, resulted in a very 
smooth animation in NS4.X, Opera and MSIE - also on slow machines!
Think the problems are somewhere else ... as you analyzed via Jprof.

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

I'll stick by my guns and say the JS code is poorly written - the animation
speed is highly dependant on CPU speed on all but very fast computers.  Updating
the position of the text 1000 times a second is silly if the monitor refreshes
at most around 100 times a second, usually more like 75-85.

That said, it also points out some issues with our execution of that code, and
interfacing with timers.  So I consider the JS code to be bad, but the bug to
also be real.

Comment 19

[Fabian Guisset]

FWIW, changing the timeout to be anything between 1 and 20 doesn't change the
speed of the animation. It's as fast as it gets. Above 20ms, the animation gets
gradually slower, at least in my tests, but I guess that depends on your
computer as well. So you can change the timeout to 20ms if you wish, but we're
still slower than other browsers.

Comment 20

[Randell Jesup [:jesup] (needinfo me)]

How about 20ms with my patch?  Note that my jprof shows that part of the issue
is reflow...

Comment 21

[Markus Hübner]

Made an interesting discovery: when removing the CSS the animation 
is much smoother (1.1ghz, win-xp) and nearly double as fast when testing on a 
slower PIII,500MHZ (build 2002020208 on win2k).
The page without the CSS is at
http://www.world-direct.com/mozilla/dhtml/index_no_css.html

What does this tell us?

Comment 22

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

Can you figure out which css property is the cause?

Comment 23

[timeless]

99:1 left

*** This bug has been marked as a duplicate of 70156 ***

Comment 24

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

Why don't we just mark every bug as a duplicate of a bug called "Mozilla has
bugs"?  It looks like this bug was describing a specific problem.

Comment 25

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

And, FWIW, the CSS property in question is *not* the one that causes the
animation to happen, since comment 21 says the animation runs more smoothly.

Comment 26

[Aaron Kaluszka]

I don't even see a problem on 2002020208/WinXP (Dual Athlon XP 1700+/1GB DDR266
Reg ECC RAM)  Might just be my machine though.

Comment 27

[Manfred Schneiderbauer]

I found out that a delay appears when wrapping animated elements into a
big-sized container element. In the herewith mentioned test case, I wrapped the
animations into an 8000 by 8000 pixels empty div. When a div with the same size
appears to not wrap the animation (but nevertheless overlaps it), no visible
delay appears. Both situations can be tested on the test case page.

The test case URL is:
http://www.world-direct.com/mozilla-testcases/107746_dhtml-animations-performance/index.html

I've been using Mozilla 0.9.8+/20020202 on Win2k at 1600x1200/32.

Comment 28

[Markus Hübner]

That would also explain comment #21 why
http://www.world-direct.com/mozilla/dhtml/index_no_css.html
is running more smoothly than
http://www.world-direct.com/mozilla/dhtml/index.html

Comment 29

[Johnny Stenback (:jst)]

Pushing to mozilla1.0

Comment 30

[Johnny Stenback (:jst)]

Duping against our DHTML perf tracking bug.

*** This bug has been marked as a duplicate of 21762 ***

Comment 31

[Markus Hübner]

We have a very nice testcase here and have already done some investigation.
A real 1.0 bug since this one affects some top100 sites as well.

Comment 32

[Nisheeth Ranjan]

This specific DHTML bug won't get any attention for mozilla1.0, good things are
happening in bug 129115 that should make a world of difference here too.

Comment 33

[Mike Shaver (:shaver emeritus)]

This site actually doesn't work on the 129115 branch right now, thanks for the
find.  I'll add it to our test list.

Comment 34

[Johnny Stenback (:jst)]

Um, the above comment from Nisheeth was a comment from me, using Nisheeth's
account w/o realizing.

Comment 35

[Markus Hübner]

This bug is also a perfect example of the recent regression bug 129953.
Bug 129115 is a nice thing, but we need further tweaking on bug 117061 !

Comment 36

[Markus Hübner]

if you go to http://www.world-direct.com/mozilla/dhtml/index.html
clicking on 'company' things are very lame

if you go to http://www.world-direct.com/mozilla/dhtml/index2.html
things are rocking :)

what's the difference?
in the slow example there is a div below the other animated div
elements. this base-div (coordinates 0|0) has a red margin.

Comment 37

[Markus Hübner]

oh - forgot the faster testcase also has no background-image.

Compared to the very slow testcase things are a bit faster
(then there is no matter if that's the base-div or the background image).

So http://www.world-direct.com/mozilla/dhtml/index4.html
[having the base-div and no background-image]
is actually as fast as
http://www.world-direct.com/mozillas/dhtml/index5.html
[having no base_div but with a background-image]

Comment 38

[Markus Hübner]

Using trunk build 2002061204 
http://www.world-direct.com/mozilla/dhtml/index5.html
is perfectly whereas http://www.world-direct.com/mozilla/dhtml/index4.html is
noticeable slower.

Does this provide any clues?

Comment 39

[Boris Zbarsky [:bzbarsky]]

Has anyone bothered to address comment #22?  That seems like the obvious first
step...

Comment 40

[José Jeria]

Went through the css file and noticed that the css class for the menu is the 
problem:

#menu {
	LEFT: 0px; 
	POSITION: absolute; 
	TOP: 0px; 
	Z-INDEX: 2;
}

removing the position:absolute; makes the menu animation very smooth.

Comment 41

[Markus Hübner]

So this is related to bug 75121

Comment 42

[Randell Jesup [:jesup] (needinfo me)]

I believe bug 75121 is at least part of this problem, if not all of it (probably
all of it).  Since this bug depends on 75121, when it's fixed we should see if
this is still an issue and if not close it.  Or close this as a dup now.

Comment 43

[José Jeria]

Now that bug 75121 has been fixed there is till difference in speed between the
url:s mentioned in comment 38.

Comment 44

[Markus Hübner]

what trunk build have you been using ?

Comment 45

[José Jeria]

Latest build 2002092404.

Comment 46

[Markus Hübner]

In build 2002092404 bug 75121 isn't included (this is from 04:00 am) and bug 
has been checked in at 2002-09-24 05:14 
Give it a try with todays trunk build.

Comment 47

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

If you look closely at index4 and index5, the DHTML effects are actually
different. index5 brings the bottom menu element across the page ahead of the
middle element, index4 brings it across last. What's going on there?

Comment 48

[Adam D. Moss]

FWIW, here (on Linux/GTKfe, 400mhz machine) index{,2,3,4,5}
all run very poorly with no obvious difference in speed
between any of them.  This is with a CVS trunk build
at time of writing (ie. including the happy fun bug 75121
fix).

Comment 49

[Adam D. Moss]

Ugh.  I retract that last comment unconditionally, since
I am a space cadet and happened to be running the original
Mozilla 1.0 release, not my trunk build.  I should sleep
more or develop a caffeine habit.

Comment 50

[Markus Hübner]

strange difference in the testcases.
well, here are the two:

1) with background image
http://www.world-direct.com/mozilla/dhtml/index_withbg.html

2) without background image
http://www.world-direct.com/mozilla/dhtml/index_withoutbg.html

Comment 51

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

Actually, I think my previous commen might have been completely wrong.

Comment 52

[José Jeria]

WFM, 2002112008 Windows 2000

Comment 53

[Markus Hübner]

Using trunk build 2002111908 on winxp pro,1.1ghz,512ram,geforce2go 32mb@32bit, 
the first testcase in comment #50 is slower then the second.
Don't know how far the background image does affect the sliding performance.
There is still a visible difference between the speed in Mozilla and 
MSIE/Opera - even NS4.78 is faster.

Comment 54

[Garrett Smith]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 
Chimera/0.6+
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130

http://www.world-direct.com/mozilla/dhtml/index_withbg.html
http://www.world-direct.com/mozilla/dhtml/index_withoutbg.html

Not very smooth, but it works. Smoother in Chimera. Slide time is about 1.5-2 sec. I am 
on a G3 350 MHz


WFM

Comment 55

[Markus Hübner]

Using trunk build 2003011414 comment #53 is still true.
Maybe we have a painting performance problem  here.

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

something that may or may not be of interest: if I click on "company" on the
above url, the sliding in of the menu entries makes playing the mp3 playing in
the background temporarily stop, using netscape 7.02 on windows.

Comment 57

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 58

[Markus Hübner]

using trunk build 2003052504 on winxp pro sp1, 512ram, 1.1ghz the testcase got 
even slower.
This seems to be caused by bz's arch changes (this perf regression has also 
been described in bug 201082, comment#2) - do hope that we will be back up to 
where we were resp. be faster in the not too distant future.

Comment 59

[Markus Hübner]

Testing with trunk build 2004081109 on win-xp pro sp1 there are unfortunately 
no perf improvments, did test all testcases as reported in the bug.
Maybe a profile will reveal more here.

Comment 60

[Boris Zbarsky [:bzbarsky]]

Profile doesn't really show much past us spending time reflowing, recomputing
style, painting.

Of course it also shows that we're idle half the time, so if there's a perf
issue it's not due to pure CPU usage....  Does IE have a minimum 10ms timeout
like Mozilla does?  If the site is changed to use 10ms timeouts, how does that
affect IE's and Mozilla's behavior?

Comment 61

[Markus Hübner]

AFAIK IE also has a minimum 10ms timeout.

Comment 62

[Martijn Wargers (dead)]

Attachment: testcase

Results with this testcase:
Mozilla1.1:	  1392ms
Mozilla1.2:	  1743ms
Mozilla1.7:	  1732ms
2005-07-03 build: 1231ms
Opera8: 	  841ms
IE6:		  841ms
I think that current Mozilla builds are slower here because of bug 257454.
(although it also uses quite some cpu on this testcase, compared to IE6 and
Opera8, but that's not the deciding factor here).

Comment 63

[Markus Hübner]

Doing a profile of the recent testcase would bring some more light here.

Comment 64

[Boris Zbarsky [:bzbarsky]]

There's nothing to profile.  The limiting factor on this testcase is the timeout
delay -- the CPU is 50% idle when the testcase is running.  Given bug 257454,
one would expect exactly the results listed in comment 62.

In any case, the actual problem this was filed on seems to be fixed (the 4x
discrepancy from comment 0).  Marking worksforme; there's nothing else to really
do here.

Comment 65

[Markus Hübner]

Though the performance with the most recen trunk build is visible worse 
compared to MSIE6 with former testcases I can agree with marking this bug WFM.

Let's better put our energy in bug 291386 or 257454.