Poor DHTML animation performance at former sony.com site




17 years ago
5 years ago


(Reporter: fehe, Assigned: jst)


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

perf, testcase, top100
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment)



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

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


17 years ago
Assignee: asa → jst
Component: Browser-General → DOM HTML
Ever confirmed: true
Keywords: perf, top100
QA Contact: doronr → stummala
Summary: Rendering of web content extremely slow compared to IE6.0 → Poor DHTML animation performance at www.sony.com

Comment 2

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

17 years ago

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.


Comment 4

17 years ago
this is a DOM level 0 bug. added comments in bug # 21762
Adding block: bug 21762.
Blocks: 21762

Comment 6

17 years ago
marking this bug as dup of bug 21762 

*** This bug has been marked as a duplicate of 21762 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 7

17 years ago
verified dup
How can this be a dupe of a tracking/meta bug?
Resolution: DUPLICATE → ---

Comment 10

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

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

17 years ago
then again might be related to bug 103558

Comment 13

17 years ago
This does not seem related to bug 103558.

Comment 14

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

basic@yahoo.com 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

17 years ago
Created attachment 55967 [details]
testcase with sliding text only (depends on files at www.sony.com)

Comment 16

17 years ago
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
Severity: normal → major


17 years ago
Keywords: testcase

Comment 17

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

Comment 18

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

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

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

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


17 years ago
Keywords: mozilla1.0
OS: Windows 2000 → All
Hardware: PC → All


17 years ago
Priority: -- → P2


17 years ago
Keywords: mozilla1.0+


17 years ago
Keywords: mozilla1.0


17 years ago
Keywords: nsbeta1

Comment 22

17 years ago
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.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.0.1

Comment 23

17 years ago
Um, that was a comment from me, not from Nisheeth.


17 years ago
Keywords: mozilla1.0+ → mozilla1.0-

Comment 24

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

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

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

Comment 27

17 years ago
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...
Last Resolved: 17 years ago17 years ago
Resolution: --- → WORKSFORME

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

Comment 29

17 years ago
Resolution: WORKSFORME → ---

Comment 30

17 years ago
URL: xlat.assembler.org
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
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

17 years ago
Using trunk build 2002071108 on win-xp pro,1.1ghz,512ram
is still considerably slower than msie.
Think bug 75121 will ease things here.
Depends on: 75121


16 years ago
Target Milestone: mozilla1.0.1 → ---
With build 2003010408 WinXp Athlon1700xp/2156MB this site is displayed faster in
Mozilla than in IE ! I think the bug should be fixed
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?
Summary: Poor DHTML animation performance at www.sony.com → Poor DHTML animation performance at former sony.com site
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

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

Marking as WFM due too lack of opositions
Last Resolved: 17 years ago16 years ago
Resolution: --- → WORKSFORME


14 years ago
No longer blocks: 21762
Blocks: 21762


10 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.