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
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
How can this be a dupe of a tracking/meta bug?
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> :-) email@example.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.
Created attachment 55967 [details] testcase with sliding text only (depends on files at www.sony.com)
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
*** 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.
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.
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
Last Resolved: 17 years ago → 17 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.
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
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
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → WORKSFORME
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.