Closed Bug 244555 Opened 20 years ago Closed 19 years ago

Very slow scrolling on http://www.exactaudiocopy.de/

Categories

(Core Graveyard :: GFX: Win32, defect)

Product:
Core Graveyard
Component:
GFX: Win32
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: pavel.penaz, Assigned: sring)

References

(
URL
)

Details

(Keywords: perf, regression, testcase)

Attachments

(2 files)

image for testcase
7.40 KB, image/gif
Details
Simplified testcase of slow scrolling, CPU 100%
277 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040524 Firefox/0.8.0+

Whenever I visit http://www.exactaudiocopy.de/ and use mouse scroll wheel, the
browser becomes very sluggish and unresponsive.

Reproducible: Always
Steps to Reproduce:
1. visit the page http://www.exactaudiocopy.de/
2. scroll on the page with a mouse wheel
3. 

Actual Results:  
The scrolling takes very long time, browser uses a lot of CPU, mouse moves very
slowly
Component: Browser-General → General
Product: Browser → Firefox
Version: Trunk → unspecified
Flags: blocking1.0?
Flags: blocking0.9?
WFM, may be a dupe, but it'd be a layout/content issue which is beyond what
we'll be able to fix in 1.7

if there was a reduced testcase and fix, we'd possibly take this
Flags: blocking1.0?
Flags: blocking1.0-
Flags: blocking0.9?
Flags: blocking0.9-
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040524
Firefox/0.8.0+
Attached image image for testcase — 
This is an image with a large transparent area.
This is a simplified testcase of that site.
They use a large, for the most part, transparent background-image. That seems
to slow down Mozilla considerably. 
I use:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040523
Firefox/0.8.0+

I don't think this is something specific for Firefox.
I think this is related to bug 244582.
Because the dates mentioned in bug 244582, comment 3 are the same as where here
the performance decrease occurs.

So:
Slow scrolling occurs in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/2004-03-17
Firefox/0.8.0+

But it doesn't occur in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/2004-03-11
Depends on: 244582
Keywords: perf, regression
WFM : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040719
Firefox/0.9.1+
Config is : P4 2.7 GHz, 1 GB RAM, SiS 651 VGA (sisgrp.sys) @ 1280x1024x16 bits.
All right, I could take as much as 50 % of the CPU, but only by mad scrolling.
No mouse lag at all.
when I try to access this website
http://www.mcli.dist.maricopa.edu/show/nmc1003/
the firefox 1.0 PR eats a lot of CPU! my laptop almost cannot do anything else 
for a while. Then it's OK.
When I try this link with other browsers it works well. Any problem with the 
extentions to read this "macromedia Breeze"?
Confirming Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040910
Firefox/0.10

I can see slow scrolling with autoscroll. Scrolling with scroll bars or
mousewheel is somewhat slower, but does not affect usability for me.
Depends on: 205893
Can confirm and add another example of this
http://people.debian.org/~srivasta/talks/why_debian/talk.html

Saved a plain html page without images, page still takes 100% CPU while scrolling.
Stefan, assigning to you because it looks like your patch caused this... Please
let me know if you won't be able to look into this, ok?

Also ccing reviewers from bug 205893.
Assignee: general → sring
Component: General → GFX: Win32
Flags: blocking0.9-
Keywords: testcase
Product: Firefox → Core
Version: unspecified → Trunk
Flags: blocking1.8b?
QA Contact: general → ian
I think this is a good testcase to quantify performance:
http://www.world-direct.com/mozilla/dhtml/75121/anim-test.htm
(from bug 157072)

Firefox 20040302 build: 1732ms
Firefox 20040316 build: 3936ms

I'm using a Duron 600MHz, 512MB mem, NVidia GeForce2 MX 100/200, 1024*768pixels,
16 bits color depth.
Flags: blocking1.8b? → blocking1.8b+
I went to the site, and it appeared to be fine, then the images loaded in the
frame and it does slow down considerably.  Not only is the scrolling slowed down
but when u tab in and out it also takes a few secs to load.  I have noticed this
on other sites that have hugh flash creations.  So it might be a web page size
thing.  Hope someone is able to find a fix to this peculiar problem.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0
AMD 64bit 3000+, 1gig ddr 333, geforce 6800 gt, 1600x1200 32bits.
Confirming. The testcase is notably slower on Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.8b) Gecko/20050215 Firefox/1.0+
Stefan, have you had a chance to look at this? We really can't afford serious
performance regressions in the upcoming gecko 1.8 releases. Moving blocking to
b2 and 1.1
Flags: blocking1.8b2+
Flags: blocking1.8b+
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0-
Hmm, the backing out the patch from bug 205893 seems to make the performance of
the testcase in comment 11 slightly worse.
Tested with 800 MHz Duron, NVidia TNT2 M64 32MB:
32bits color depth:
6850ms, before backing out
7100ms, after backing out

16bits color depth:
3685ms, before backing out
4146ms, after backing out

But backing out the patch still makes this bug disappear, though. 
So the testcase mentioned in comment 11 is not a good testcase for this bug,
after all.
This could be the old problem with transparent images and NVidia graphics
cards/drivers. See bug 255648, bug 260676, bug 278614
I got same problem after I changed my graphic card from radeon 9600xt to geforce
6800.

in test from comment 11 i have 9,5 seconds in average. 

most interesting that when i turning on DualView or Clone view Firefox works
perfect. i have 1,4 second in test (but 3D speed droping heavily, so can't use it).


Can someone confirm that this bug is partially fixed in todays build? I get
slower scrolling only when the upper gif image is on the screen, otherwise the
scrolling is smooth.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050305
Firefox/1.0+
Probably helped along by the patch in bug 284716 (which explicitly mentions this
bug as one of the things it will help along).
Depends on: 284716
Well, for me this bug looks totally fixed now. It is much smoother in today's
builds as in builds before 2005-03-5.
Tested with 600MHz Duron/NVidia Geforce2 MX 100/200 16 bit color depth and
tested with 800MHz Duron/NVidia TNT2 M64 16 bit color depth.
Marking fixed (by bug 284716).  Certainly the regression Stefan caused (which is
what's blocking 1.8b2 here) is fixed.

If people are still seeing issues, please file new bugs with specific data on
the issues (eg whether the same issues are present in Firefox 1.0).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I saw where this had been fixed, I think great. I'll try a current build & see
if it is so.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050312

I install the above on my "mule", open the EAC webpage, smooth scrolling.  I say
great! I'll install on my regular machine.

I do so, open the EAC webpage, still terrible.  Help | About Mozilla.  Sure
enough I have the same exact build running on two different computers.

Would think it is a video card issue then?
Both WinXP SP2.

Mule: VIA/S3G UniChrome IGP 64MB
Installed Drivers: vtdisp (6.14.10.0194-16.94.42.03)
16 bit color quality

Regular: NVIDIA GeForce4 MX 440 with AGP8X 64MB
Installed Drivers: nv4_disp (6.14.10.5672 - nVIDIA Detonator 56.72)
32 bit color quality

Aha, getting somewhere. Mess around making changes to GF4.
16 bit color.  No difference.
Mess around with the GF4 driver settings.  Not that I know what I'm doing, but I
turn them all off to the best of my ability.  No differences.
I've often heard about the "Hardware accelearation" setting in Display
Properties.  Both systems are set to Full.

Change the GF4 to None, EAC problem DISAPPEARS.

Further checking shows that any setting, other then Full, works!

The setting one step down from Full says, "Disable cursor & bitmap
accelerations.  Use this setting to correct problems with the mouse pointer, or
to correct problems with corrupt images".

When left on Full, IE on the same system does not experience any problems with
the EAC website.

So that would tend to indicate some sort of interaction between Mozilla & NVIDA?
Results from the testcase in #11:

Hardware acceleration:

Other then Full, 1594ms
Full, 6969ms
therube: You have to install latest trunk build, this bug is not fixed on branch.
Excuse what I have posted above.

My above observations do not apply to ...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050312

This build 1.8b2 (I hope [i]it[/i] is correct for the testing here!) does work
just fine on the EAC website regardless of the "Hardware acceleration:" settings.

Results from the testcase in #11:

Hardware acceleration:

Other then Full, 1594ms
Full, 1610ms
Just a side note.
This now seems to be working correctly with the 1.7.6 release.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319
All right, call me an idiot.
This is not resolved in the Mozilla 1.7.6 release.

Don't know what I was looking at.  Perhaps I was on a different machine that
wasn't affect by this to begin with?  In any case, eventhough this bug does not
apply to 1.7.6, the 1.7.6 release is still affected by this.
Yes, this is not fixed in the 1.7.6 release (or in the Firefox1.0.2 release).
those releases in genereal only get security updates.
This is fixed in the nightly trunk builds:
http://ftp.uni-erlangen.de/pub/mozilla.org/firefox/nightly/latest-trunk/
http://ftp.uni-erlangen.de/pub/mozilla.org/mozilla/nightly/latest-trunk/
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: