104593 - Poor DHTML animation performance at former sony.com site

Status: RESOLVED WORKSFORME

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

Description

[IU]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
BuildID:    2001101117

Simply compare the performance of navigating the main page of the www.sony.com 
website and you'll see that mozilla is rendering web content at an extemely 
slow speed compared to Internet Explorer 6.0.

This is true for every website I've visited

Reproducible: Always
Steps to Reproduce:
1. Go to www.sony.com
2. Note how slow the text of the .gif animation slides in from the left of the 
page.
3. Hover over menus on the www.sony.com web page (don't click a link).

Actual Results:  Exactly what was stated.

Expected Results:  The contents should be rendered as fast as or at least very 
close to the same speed that Internet Explorer 6.0 can.

Comment 1

[Igor Furlan]

Yes, you are right. Mozilla is at least 2 times slower than MSIE.
Mozilla is slower compared to MSIE which runs within "vmware" on
the same LINUX box.  So, I am assuming that runing MSIE natively
would show even bigger difference in speed.

In general, mozilla is still dog slow. It does not matter
which URL you pick. When you browse extensively for more
than 10 minutes and open 4-5 browser windows, mozilla behaves like
being on the modem 33K....

BTW: my box is connected to the net via DSL

Comment 2

[gavin long]

I see this too, Win98SE, 0.9.5 (2001101117)

Reporter, I reckon that this is another example of Moz's general performance
problems with DHTML (bug 21762 is the tracking bug for such issues)

Confirming, adding perf, top100 keywords, moving to DOM HTML

If I read this right, we have a group of <div>s, containing transparent gifs,
being moved out from behind the menu on the left.  This could be a dupe of one
of the bugs tracked by 21762, but I don't feel remotely qualified to figure out
which (if any).

Comment 3

[IU]

Gavin,

You're right.  This is related to http://bugzilla.mozilla.org/show_bug.cgi?
id=21762 .  Therefore, if this issue was brought to the attention of the 
Mozilla development team way back then, why do they insist on ignoring it?  How 
on earth do they expect to convince everyone to ditch their ferraris and drive 
your Yugo instead?

I'm not sure how they'd explain the .gif issue, though.  Come on, it's a .gif.  
Transparent or not, why the heck is it so slow?

Please fix these, as it doesn't matter how fast Mozilla can render HTML, if it 
absolutely blows when it comes to dynamic content.

Thanks

Comment 4

[Sivakiran Tummala]

this is a DOM level 0 bug. added comments in bug # 21762

Comment 5

[Ashley Bischoff (blog at handcoding.com)]

Adding block: bug 21762.

Comment 6

[Sivakiran Tummala]

marking this bug as dup of bug 21762 

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

Comment 7

[Sivakiran Tummala]

verified dup

Comment 8

[Ashley Bischoff (blog at handcoding.com)]

How can this be a dupe of a tracking/meta bug?

Comment 9

[Ashley Bischoff (blog at handcoding.com)]

Reopening.

Comment 10

[Johnny Stenback (:jst)]

Due to the *huge* amount of DHTML performance bugs that are already reported
against mozilla we've decided to mark them all dups against a tracking bug and
once the general problems are fixed we'll undupe the ones that are truly not dups.

This one is special tho, I'm working on this bug so lets leave this one unduped
for now.

Comment 11

[basic]

this is at least partially fixed in the patch for bug 92248. I think it should
be marked as dup of 92248. It is only the first hover that is slow in the trunk
(build 2001102903 win32)

Comment 12

[basic]

then again might be related to bug 103558

Comment 13

[Johnny Stenback (:jst)]

This does not seem related to bug 103558.

Comment 14

[IU]

With you guys not being able to agree on how to categorize this bug report, I 
wonder if the bug itself will ever get fixed> :-)

[e-mail] wrote:
> "this is at least partially fixed in the patch for bug 92248. I think it 
should be marked as dup of 92248. It is only the first hover that is slow in 
the trunk (build 2001102903 win32)"

Note that it's not just the menus that are slow.  The .GIF animation with the 
text sliding in from the left is also very slow.

Comment 15

[basic]

Attachment: testcase with sliding text only (depends on files at www.sony.com)

Comment 16

[Markus Hübner]

Especially in view of the image (in public as well in the web-dev community) 
this bug is causing some trouble.
The not so sophisticated user might think mozilla is that slow in generell when 
viewing www.sony.com

This one might also be related to  bug 107746

Comment 17

[Johnny Stenback (:jst)]

*** Bug 100206 has been marked as a duplicate of this bug. ***

Comment 18

[Markus Hübner]

The new timer code seems to have had a strange affect - now there is no 
animation at all - just the last "frame" of the animation, the final positioned 
picture elements, are bing displayed.
same on bug 107746.

Comment 19

[basic]

matic: I'm not sure why on your machine it shows no animation. It seems to work
fine here except when there are delays due to slow loading of images and images
loading after the animation starts (which makes the animation jerky or jumps). I
suspect the new timer might be exposing some reflow issue.

Comment 20

[gavin long]

FWIW, I see much the same as Markus:  The various images on the page arrive
slowly, but the moving images just appear in their final positions, all in one
go, shortly  after everything else has finished loading.  Win98SE, 2001121803

Comment 21

[gavin long]

Just a couple more datapoints :

1) the effect Markus and I see is present in the 12/18 and 12/28 nightlies, but
is NOT present in 0.9.7, which implies that it went in between 12/14 (0.9.7
branch) and 12/18.  Which ties in with _basic's comment about "the new timer",
which I believe is referring to bug 78611.

2) I _do not_ see this problem with the testcase, which runs quickly and
smoothly here with 2001122803

I agree with Markus in suspecting that this bug and bug 107746 are, at least,
closely related, so I await (since I'm not in a position to build) rjesup's
patch mentioned there (itself on bug 117061) with interest.

Comment 22

[Nisheeth Ranjan]

This specific DHTML perf bug won't get any attention for mozilla1.0, but bug
129115 should improve the performance on this page as well (and intial tests
confirm this), that's about all we'll have time for in the mozilla1.0 timeframe.

Comment 23

[Johnny Stenback (:jst)]

Um, that was a comment from me, not from Nisheeth.

Comment 24

[Markus Hübner]

Testing a build with bug 129953 and bug 129115 this is still very slow.
Further tweaking of 129953 resp. 117061 will be necessary.

Comment 25

[gavin long]

Arg.  Sony have redesigned their site, and it looks like there's no animation on
the front page any more.  The testcase attachement is also broken, since it
relies on files at sony.com that aren't there any more.  Looks like we'll have
to go elsewhere for DHTML perf testcses, folks...

Comment 26

[basic]

can we resolve this now? Or does someone have a testcase based on the original
sony site?

Comment 27

[Johnny Stenback (:jst)]

Marking WORKSFORME now that the page changed, if the original page (or a similar
page) is avaliable somewhere, please reopen and point us to the page...

Comment 28

[Sören 'Chucker' Kuklau (gone)]

http://web.archive.org/web/20011031033620/http://www.sony.com/index.html

Here's a version without the actual images. IE still displays it a lot faster.

Comment 29

[Markus Hübner]

Reopening

Comment 30

[Manoj]

URL: xlat.assembler.org
OS: WinXP
Build: 2002061108

Mozilla consumes ~100% (98% - 100%) of CPU resources on my single proc P4 1.6GHz
machine when displaying this page. It renders the page pretty fast but the CPU
consumption is intolerably high.

Reproducible: Always

Comment 31

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #30 From Manoj Mehta 2002-06-12 17:04

This comment is about the old SONY.com site's animation. Please file seperate bugs.

Comment 32

[Markus Hübner]

Using trunk build 2002071108 on win-xp pro,1.1ghz,512ram
http://web.archive.org/web/20011031033620/http://www.sony.com/index.html
is still considerably slower than msie.
Think bug 75121 will ease things here.

Comment 33

[Pascal Chevrel:pascalc]

With build 2003010408 WinXp Athlon1700xp/2156MB this site is displayed faster in
Mozilla than in IE ! I think the bug should be fixed

Comment 34

[Sören 'Chucker' Kuklau (gone)]

Pascal: are you sure you tested with the URL
http://web.archive.org/web/20011031033620/http://www.sony.com/index.html , and
not with the current SONY home page?

Comment 35

[Pascal Chevrel:pascalc]

yes, and I just clocked the times with a stopwatch :

IE6SP1 : 62 seconds
MOzilla 2003010408 : 29 seconds

I have http1.1 pipelining enabled

Comment 36

[Markus Hübner]

Well, I think we can mark this WFM - the archive-URL works fine so far, though
it isn't a 100% comparable as the sliding images are not loaded, that will make
a difference on painting perf I think.

I'd say we better focus on bug 107746 where I see still MSIE6/Opera be
faster/smoother than Mozilla (trunk 2003010608 on winxp pro).

Comment 37

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

Marking as WFM due too lack of opositions