Closed Bug 107746 Opened 23 years ago Closed 19 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: markushuebner, Unassigned)

References

(
URL
)

Details

(Keywords: dom0, perf, testcase, Whiteboard: DHTML)

Attachments

(2 files)

jprof dual-450 P3 Linux RH7.1 -O2 --disable-debug
211.79 KB, text/html
Details
testcase
5.11 KB, text/html
Details 
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
Blocks: 21762
Keywords: dom0, mozilla0.9.7, nsCatFood, perf
are the "menus" supposed to do anything but display? They aren't indicated as
links and clicking them does nothing..
In this testcase they just slide in - nothing more :)
But enough to show the poor DHTML performance.
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.

The complete animation takes about 1sec on msie6 and 11secs with build 
2001110209 on win2k.
Blocks: 71668
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"?
No longer blocks: 71668
Btw, the same phenomenon appears as well in K-Meleon Version 5 Build 500 
(Win2k).
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.
Keywords: testcase
Seems this one is also related to bug 104593 hurting some top100 sites.
Target Milestone: --- → mozilla0.9.8
Keywords: mozilla1.0
Blocks: 113492
Keywords: top100
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.

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.
URL: http://www.world-direct.com/mozilla/d... → http://www.world-direct.com/mozilla/d...
bug 117061 is refering to this problem described!

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.
See 117061; I have a proposed patch that may help you and fixes your test case
(it seems).
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.

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.



Jprof.	Note: remote X, not real-time.	period = .0015.  fresh pull/build 12/28
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.

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.
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.
OS: Windows 2000 → All
Hardware: PC → All
How about 20ms with my patch?  Note that my jprof shows that part of the issue
is reflow...
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: nsbeta1
Blocks: 110029
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?


Can you figure out which css property is the cause?
99:1 left

*** This bug has been marked as a duplicate of 70156 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
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.
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.
Pushing to mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Duping against our DHTML perf tracking bug.

*** This bug has been marked as a duplicate of 21762 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Summary: [DHTML] Sliding menu performance → DHTML Animations running slow when animated elements are wrapped by a larger-sized container element
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
Status: REOPENED → ASSIGNED
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1
This site actually doesn't work on the 129115 branch right now, thanks for the
find.  I'll add it to our test list.
Um, the above comment from Nisheeth was a comment from me, using Nisheeth's
account w/o realizing.
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 !
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.


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]
Keywords: mozilla1.0, nsbeta1- → mozilla1.1
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?
No longer blocks: 113492
Whiteboard: DHTML
Depends on: 157681
Has anyone bothered to address comment #22?  That seems like the obvious first
step...
Keywords: top100
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.
So this is related to bug 75121
Depends on: 75121
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.
Now that bug 75121 has been fixed there is till difference in speed between the
url:s mentioned in comment 38.
what trunk build have you been using ?
Latest build 2002092404.
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.
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?
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).
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.

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
Actually, I think my previous commen might have been completely wrong.
Target Milestone: mozilla1.1alpha → ---
WFM, 2002112008 Windows 2000
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.
Keywords: mozilla1.1 → mozilla1.3
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

Using trunk build 2003011414 comment #53 is still true.
Maybe we have a painting performance problem  here.
Depends on: 170330
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.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW
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.

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.

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?
AFAIK IE also has a minimum 10ms timeout.
Attached file 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).
Depends on: 257454
Doing a profile of the recent testcase would bring some more light here.
Keywords: qawanted
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.
Status: NEW → RESOLVED
Closed: 23 years ago → 19 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: