Closed Bug 123493 Opened 23 years ago Closed 15 years ago

Performance: fairly simple page causes > 60% CPU usage on 1.3Ghz Athlon.

Categories

(SeaMonkey :: UI Design, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: dylang, Assigned: samir_bugzilla)

References

()

Details

(Keywords: perf)

I think this has to do with how the central pane flows over the background
image.  Basically, mozilla-bin uses about 1% of CPU time, but X spends a lot of
time (50%+) spinning its wheels.  The window updates slugishly.  Either Moz is
using a very poor way of updating the page to my X server, or the X server has
some kind of deep seated performance issue.  I'm hoping the X11 expert for Moz
will know what's wrong.

If someone could reproduce the "jerky updates" on Win9x/NT by scrolling the page
by mousewheel, I'd say this is a valid bug for all OSes.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020202
how do you mean >60% ? while scrolling or when the page is loaded? for me, on
WinXP, latest build (2002020409) scrolling up and down constantly by mousewheel
causes about 60% CPU (Thunderbird 1GHz) usage on mentioned URL, that's right.
But it's also about 15% on this bugzilla page. and the other pages layout is
simply more complex.
When page is loaded and not scrolled we're about 0-1% as is usual. i made a test
using IE6 scrolling up and down on the page you meant, and it's consuming about
50% CPU, so i think there is no 'bug' with mozilla. not even a big performance
issue. if it's not eating up your performance, when you're NOT scrolling, i
suggest marking this one INVALID.
Keywords: perf
It is very slow to scroll using XFree86 4.1 and mozilla 0.9.8. On my Duron 800
it's usable but not pleasent at all. If there is something to be done for
performance in this case then I would be happy.

I tried the page using IE 5.0 on my PII-400, and it shows no sign of slowing down 

IE uses like 70% CPU while scrolling and feels smooth. Moz 0.9.8 uses 100% CPU
and is very bad scrolling (maybe not even 400% CPU is enough, is the feeling).
It's because of the fixed background. You can't just scroll the page, it has to
be completely redrawn.
Can't we just invalidate the parts that are "changed" ?  If a page has one
central column and big margins on either side, can't we just not redraw the side
margins?

There must be some sort of algorithm for that kind of graphics work.
I don't know how it's implemented in mozilla, but if one renders the different
layers separatly and use the XFree86 RENDER extension to compose the images that
sounds like it can take away some of the slowness. But of course it will never
be as fast as when you just scroll the existing image and just invalidates a
small part of the screen as "normal" scrolling do.

But this is probably something for future versions of mozilla.

Since IE in windows is way faster then mozilla there are clearly room for
improvments here, but some profiling is of course needed to really know what the
slowest part is.
Confirming this. Scrolling the same page in Opera 6.2 Beta Linux never seems to
use more than 45% of the cpu and doesn't feel nearly as slow as in moz. 20020421
Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
WorksForMe using FizzillaCFM/2002071208. Scrolling the URL results in at most
~50% CPU usage by Mozilla.
I still see incredibly heavy CPU usage on Linux/X11 with 2002071304.  Mozilla
starts chewing between 10-20% CPU time, and X has a heart attack and takes
everything it can grab (70-90%).  It gets so bad that my CPU meter doesn't
update, and when I stop scrolling the window, it keeps "ghost scrolling" as the
input buffer replays all the queued input.

Something in Mozilla doesn't handle the background image/layering optimally at
all.  Which I find surprising, singe things like the xv extentsion allow for
lots of really neat acceleration.
How about we try XPApps for this to start with.
Assignee: asa → sgehani
Component: Browser-General → XP Apps
QA Contact: doron → paw
Product: Core → Mozilla Application Suite
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.