Closed
Bug 147799
Opened 22 years ago
Closed 22 years ago
Serious performance issues loading certain websites
Categories
(Core Graveyard :: GFX, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 141786
People
(Reporter: cpriest, Assigned: Matti)
References
()
Details
(Keywords: perf)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3)
Gecko/20020523
BuildID: 2002052306
When loading up certain websites, or when these websites are loaded in Mozilla
it causes serious system lags and temporary freezing. Appears to be some sort of
severe rendering problem or memory leaks.
Reproducible: Always
Steps to Reproduce:
1. Load up one of the following URL's, which all contain a slightly different
layout of the code, some with Javascript, some without.
http://www.pixelcarve.com/test/index.html
http://www.pixelcarve.com/test/index1.html
http://www.dynotion.com/
http://www.dynotion.com/index1.html
2. The system will freeze temporarily during loading, and in the case of
http://www.pixelcarve.com/test/index.html and
http://www.pixelcarve.com/test/index1.html it will freeze temporarily when using
the drop down menus. For all of these sites the browser will also freeze
temporarily when it's maximized after being minimized, being brought to focus,
and when other applications (like Notepad) are closed when sitting on top of the
open Mozilla window.
Actual Results: System has serious performance problems, with both the mouse
and display freezing temporarily.
Expected Results: Should have reacted the same way it does in IE and Netscape
4, quick loading with no mouse or display freezes.
I can't figure out what's causing this. I seem to run into this issue designing
a lot of sites, but for the life of me I can't figure out what I'm doing to
cause it. For the most part these are just simple table designs using
Dreamweaver with minor tweaking. Using a DOCTYPE declaration doesn't seem to
have an effect on the system freezing, although on some pages not using one can
cause Mozilla to keep trying to transfer data from the server even if the site
has fully loaded. If it is something I'm doing that's causing it I'd really like
to know about it so I can work around it, since my sites all seem to work great
in NS4 and IE and there doesn’t seem to be any rhyme or reason for this to be
happening in Mozilla, since I can't see the difference between websites I make
that do have this problem and ones that don't.
Since Dreamweaver is pretty common, as is this very structured way of website
design, I doubt I’m the only person experiencing this and fear it could be a
Mozilla 1.0 showstopper if it’s not fixed.
It should also be noted these problems occur when the pages are loaded locally
on my machine as well, so it’s not server related.
Comment 1•22 years ago
|
||
wfm 2002052523 on linux..
Comment 2•22 years ago
|
||
WFM with 2002051006 on Win2k on Athlon600.
The first pixelcarve page uses high CPU on load, but no longer than a quarter of
a second or less. Still not a bug, in my impression. And certainly not a
critical one.
Comment 3•22 years ago
|
||
Using 2002052809/trunk/W2K for first time was testcase's menus slow, but after
some activity is reaction time of menus common.
Severity: critical → normal
Keywords: perf
Comment 4•22 years ago
|
||
WFM 2002052008 intel celeron 600
Comment 5•22 years ago
|
||
seeing the slowliness with build 2002052809 on Win2k (trunk).
This should be dupe of bug 143046 (by way of bug 143219), because of the GIF
background image being 20x2000 pixels.
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Component: Browser-General → GFX Compositor
Depends on: slowGIF
Ever confirmed: true
Comment 6•22 years ago
|
||
In bug 141786 I came up with a one line fix that takes care of this. I checked
the website in this bug.. and it really speeds things up at least anything
having to do with background scrolling. Marking this bug a duplicate of that..
and you can recheck when I get that fix into the trunk.
*** This bug has been marked as a duplicate of 141786 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 7•22 years ago
|
||
Ahhhhh... the transparent gif background image... BINGO! That's definitely
what's causing the problem. Removing it speeds Mozilla right back up, and in the
case of http://www.pixelcarve.com/test/index.html there is a transparent gif
behind the drop down menus (to combat and Netscape 4 table bug), which would
explain why those menus are so slow in Mozilla. I surmise I'm probably not the
only one using transparent gifs are background images or table backgrounds so
it's good to know there is a fix in the works for the next release, as this
would be a major problem if it made it into the final 1.0.
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•