Closed Bug 104593 Opened 23 years ago Closed 22 years ago

Poor DHTML animation performance at former sony.com site

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: fehe, Assigned: jst)

References

(
URL
)

Details

(Keywords: perf, testcase, top100)

Attachments

(1 file)

testcase with sliding text only (depends on files at www.sony.com)
1.63 KB, text/html
Details 
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.
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
Assignee: asa → jst
Status: UNCONFIRMED → NEW
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
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).
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
this is a DOM level 0 bug. added comments in bug # 21762
marking this bug as dup of bug 21762 

*** This bug has been marked as a duplicate of 21762 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
How can this be a dupe of a tracking/meta bug?
Reopening.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
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.
Status: REOPENED → ASSIGNED
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)
then again might be related to bug 103558
This does not seem related to bug 103558.
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.

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
Keywords: testcase
*** Bug 100206 has been marked as a duplicate of this bug. ***
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.
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.
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
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.
Keywords: mozilla1.0
OS: Windows 2000 → All
Hardware: PC → All
Priority: -- → P2
Keywords: mozilla1.0+
Keywords: mozilla1.0
Keywords: nsbeta1
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
Um, that was a comment from me, not from Nisheeth.
Keywords: mozilla1.0+ → mozilla1.0-
Testing a build with bug 129953 and bug 129115 this is still very slow.
Further tweaking of 129953 resp. 117061 will be necessary.

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...


can we resolve this now? Or does someone have a testcase based on the original
sony site?
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...
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
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.
Reopening
URL: http://www.sony.com → http://web.archive.org/web/2001103103...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
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.
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.
Depends on: 75121
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
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
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
No longer blocks: 21762
Blocks: 21762
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.

Attachment

General

Creator:
Created:
Updated:
Size: