Closed Bug 270900 Opened 20 years ago Closed 19 years ago

Gecko engine slower on some *simple* websites than in more complex ones, on old PCs

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: eloli, Unassigned)

Details

Attachments

(1 file)

smallest slow page that creates a scollbar on my 1024x768 full screen firefox window
2.35 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: gecko/firefox

I have this fully Linux-compatible SONY VAIO N505VX laptop that I installed
ArchLinux 0.7pre+ in it. The machine is a PII 333 Mhz, 128 MB RAM, 2.5 MB VRAM
on a Neomagic graphics card.

So, the problem is that sites that do NOT have nested tables (and they are
simingly very simple to render) are very slow to scroll through. No matter if I
use the arrow keys, or the PageUP/PageDOWN keys, or the scrollbar, the scrolling
is very painfully slow. Examples of scrolling slowness:
http://www.osnews.com/demo.html http://www.queru.com http://happypenguin.org/

However, other sites, much more complex HTML-wise, are scrolling without a
hitch! Examples of fast scrolling: http://freshmeat.net http://www.osnews.com
http://www.gnomefiles.org/

Please note the two similar OSNews links. One is the normal OSNews page (scrolls
fast) and the other one is the much simpler ad-less version for our subscribers
(scrolls slow). Especially if you think that 80% of their layout is identical,
it makes you think what really triggers the Gecko slowness problem.

I have tried Mozilla, Firefox and Epiphany on this machine, all with the same
problem. Dillo and Opera don't exhibit the problem. (Xterm does though, when it
scrolls down stuff, sometimes :P)

Please note that I have tried both the Neomagic and the VESA driver on X.org
(the Vesa driver is pretty fast on X actually). I also tried to optimize my
xorg.conf and I also went to 16bit color instead of 24bit, again without any
significant results that would help the particular problem.

Reproducible: Always
Steps to Reproduce:
1. See above.
2.
3.

Actual Results:  
Slow scrolling via any scrolling method, but only on some sites. Other sites,
even if they are seemingly much more complex or longer, they scroll just fine.

Expected Results:  
To scroll adequately fast, on all pages, especially the simple ones, because the
user expects at least them to do so.
Product: Browser → Seamonkey
Simplicity of HTML is not well-correlated to how much time it takes to paint the
page.  A simple page with a large translucent graphic will scroll more slowly
than a complex page with no graphics and just text.

I can't reproduce the performance problem you describe, unfortunately (with a
p3-733 processor here).

Could you create a minimal-ish testcase (very simple HTML/CSS page, with minimal
amount of content) that still shows the scrolling problems?
Actually, this very page is slow. But here is another, simpler page, that is
also very slow to scroll (by any means of scrolling):
http://mail.gnome.org/archives/

I think the PC you are trying is already too fast to see the problem. I run
Pentium-II Mobile, 333 Mhz Celeron, on a 2.5 MB Neomagic graphics card on
1024x768x16bit (24bit is even slower). I think the problem the graphics card,
not the cpu speed. I mean, I have a dual celeron 533 mhz too, and I don't see
the problem either, because my gfx card is a 32 mb matrox millenium. So, to
really reproduce this, you will need an older gfx card with limited vram.
> But here is another, simpler page,

If you take that page and remove the form controls, does it still scroll slowly?

> I think the problem the graphics card,

That does seem very likely.  Hence my request to try to create a minimal
testcase that shows the scrolling problem... since you can reproduce the
problem, you're actually in a position to do that.  ;)

Yes, removing the form block, it's still equally slow.
Ok... so what's the smallest page that still scrolls slowly?
That's really really odd...  That really shouldn't be slow...

If you replace links with normal text, is it still slow?

If you replace list items with paragraphs, is it still slow?
I am leaving for Europe soon and I won't have the time to fully test it.
However, I made an important discovery: The pages that I said are slow, ARE slow
EVEN on faster systems with lots of VRAM.

Please do this test for me with your PII/K6/PIII:
Go to Freshmeat.net with the Windows version of Firefox, let it load the page,
and then press the middle click mouse button, in order to start scrolling using
that autoscroller thing. Go up and down the page using that scroller, and you
will see that the page is scrolling just fine.

Now, go to the much simpler programmatically page,
http://www.osnews.com/demo.html and try the same. You will see -- if you look
closer-- that the page does NOT scroll as easily on this page! Scrolling is
visibly slower (at least on my dual celeron 533 Mhz system with 32 MB Matrox
Millenium Max and XP SP2)!

So, even if on faster machines the difference in scrolling is hardly noticeable,
there IS a difference that it doesn't make sense to exist. That difference in
scrolling speed is _extremely_ visible on slower machines with less VRAM and
makes browsing problematic to the point that I am now using Dillo with my Vaio
laptop as Firefox is unusable on most slow-scrolling pages.

So, what you guys need to do is simply profile the URLs I gave you, and find out
why these --seemingly-- simpler pages are harder to scroll. Fixing that bug or
architecture issue, should make Firefox/Mozilla faster even on fast machines,
even if fewer users will actually notice. Please profile it on your side, the
problem IS there even on fast machines!
I profiled all the urls mentioned when I first commented on this bug.  The
profiles showed no discernable differences from the "fast" urls.  Further, the
two pages listed in comment 8 scroll at the same speed as far as I can tell here.

Note also that a "simple" page with a large image will scroll slower than a
"complex" text-only page, since images just take more effort to paint...
Well, the problem is visible with my hardware and large pictures is not the
reason. some of the slow pages are almost text-only. Please make sure you have
Autoscroll and Smooth scrolling, ON.
That's the first time you mention autoscroll and smooth scrolling.  I have them
turned off, of course.  I'll see whether I can find a way to turn them on in
Mozilla Suite.
Removing these two options it makes scrolling a bit faster, yes. However, the
slowness of these pages is STILL visible on that 333 PII with 2 MB VRAM, even
without these scrolling options ON.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: