Closed Bug 216430 Opened 20 years ago Closed 20 years ago

scrolling slow due to huge background image (regression)


(Core :: Web Painting, defect)

Not set





(Reporter: jruderman, Assigned: darin.moz)




(5 keywords)


(2 files)

Scrolling using the scrollbar at is...

fast in firebird 0.6.1
fast in firebird 0729
fast in firebird 0807 \
                      | regression happened in here
slow in firebird 0809 / 
slow in firebird 0816

Test testcase shows that the problem is the huge background image.

Originally reported by Kitsunebi at
Attached file testcase
Just to confirm that this is not Firebird specific, scrolling is also slow with
Mozilla 8/15-15 under XP.
*** Bug 216720 has been marked as a duplicate of this bug. ***
This is a good example:

Mook mentioned a quick fix:
Enter this in the address bar after going there, and press enter. Scrolling
works fine again. 
 <a href="">here</a> that
putting the code below completely heals the problem.
Is this Windows only? Did Linux regress at the same time or not?
Sorry for spam, but isn't this bug a duplicate of 124150?
To cause this bug, image height must be >= 1582 or image width must be >= 1601.
Any image with smaller dimensions does not cause this effect.

I’d say the severity of this bug should be increased – it makes Mozilla almost
unusable on Celeron 1100 MHz running win2k and on AMD XP 2000+ it’s very noticeable.

Also, not only is scrolling slow but also selecting text is very slow (lags) and
hovering over links that have hover attribute set via CSS is also very slow.
Gert, is it the image *area* that matters, or is it just if the width > 1601 no
matter what the area is?
Also, CCing tor since this is most likely a GFX/image issue
This is due to the stopgap checkin for bug 205893, which turned off optimization
of images on the win32 platform.
alright then, I'll assign it to you and you can figure out what to do with it :-)
Assignee: robert → tor
Reassigning to jdunn, who did the temporary patch.
Assignee: tor → jdunn
OS: Windows XP → All
This bug seems to dramatically affect the performance of sites like and even my own blog (

Gert, none of those sites use images with the dimensions you mentioned. The
dimensions for is 700x1000,
yet the performance is much worse now compared to e.g. Firebird 0.6.

Blocking 1.5?
Flags: blocking1.5?
Forget I said anything about image dimensions – came back from weekend, tried
again and now the critical dimensions seem to have changed! Small images still
don’t cause slowdown but now image 1500x1500 will… I didn’t try to pin down the
exact values. 700x1000 pixel image still doesn’t cause slowdown for me though.

I tested it by making simple html page and then just changed background image
pixel dimensions and kept reloading.
darin, can you help on this one?  not sure if jdunn is back in action...
chofmann, sure i'll take a look once i get a win32 build env setup.  btw, this
doesn't seem to be performing badly under linux [firebird-trunk-2003-09-07].
Gert, my blog uses "background-attachment: fixed". Maybe that's the reason for
the huge slowdown? If so, is there another bug filed for that?

Fwiw though, the performance in recent nightlies is much slower than in Firebird
0.6, so something has definitely happened since then.
The good thing is that we now know at least one case where using GDI's
is helpful.

Some initial thoughts (and just thoughts...)
-create GDI's for images larger than SOME_SPECIFIC_SIZE,
 otherwise use the current scheme
-use GDI's for backgrounds (and maybe any image that we do
 compositing on (i.e. I wonder if alpha blended images also
 cause a slowdown).  This way, nsImageWin doesn't have to be
 smart but the layout engine is the one that calls nsImageWin::Optimize

I need to run some tests (with & without the fix for bug 205893)
to see the problem for myself.

Darin, thoughts?

And yeah btw, the original patch causing the regression was only on
windows.  The original problem, is still an issue on Linux (since
we never fixed it there.
as a quick fix, i think we should just make "someone" (either nsImageWin or
imagelib) enable GDI for large images.  then we can go back and do something fancy.
Attached patch v1 patchSplinter Review
ok, this simplistic patch makes it so that we _will_ optimize images larger
than 128k (that's 128Kb at 24 bpp).  worst case, i think the number of GDI
objects will remain reasonable.  consider 32Mb of GDI objects in the memory
cache... worse case is 256 HBITMAPS (256 * 128Kb = 32Mb).  i think that should
be reasonable.	now, if someone has 1Gb+ of RAM, we might start getting into
trouble.  perhaps, we should also limit the browser's memory cache to some hard
fixed limit, instead of letting it grow unbounded in size (albeit at a
logarithmic rate) as the amount of system memory increases.
Attachment #131109 - Flags: superreview?(tor)
Attachment #131109 - Flags: review?(jdunn)
-> me
Assignee: jdunn → darin
Severity: normal → major
Target Milestone: --- → mozilla1.5final
Comment on attachment 131109 [details] [diff] [review]
v1 patch

I am going to ok this, but note I have no review authority.
Attachment #131109 - Flags: review?(jdunn) → review+
simon and pav may have opinions on this...
Comment on attachment 131109 [details] [diff] [review]
v1 patch

Well, this is certainly better than the previous patch that should never have
gone in to the tree...	The Win95/98 checks are important and something I had
in my original windows image code.. perhaps they didn't get ported back when I
reverted to the nsImageWin code.  r=pavlov
Attachment #131109 - Flags: superreview?(tor) → superreview+
Comment on attachment 131109 [details] [diff] [review]
v1 patch

requesting drivers approval for 1.5 final.  i don't think we should ship 1.5
without this patch.
Attachment #131109 - Flags: approval1.5?
Comment on attachment 131109 [details] [diff] [review]
v1 patch

a=chofmann for 1.5...  lets spin off another bug for redesign work...
Attachment #131109 - Flags: approval1.5? → approval1.5+
Flags: blocking1.5? → blocking1.5+
Closed: 20 years ago
Resolution: --- → FIXED
ok, see bug 218861 for redesign work.
scrolling is definitely a lot faster in testcase.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030910
I'm not sure what the status is of 1.4.1, but this is a serious regression in
1.4.1 from 1.4.  I've seen it come up twice in the newsgroups/forums from people
testing the RC build.
Flags: blocking1.4.1?
Flags: blocking1.4.1? → blocking1.4.1+
Attachment #131109 - Flags: approval1.4.1+
Keywords: fixed1.5
*** Bug 191968 has been marked as a duplicate of this bug. ***
Keywords: fixed1.4.1
answer to comment 20 from Darin Fisher:
the 1Gb+ of RAM case isn't a problem, because Win9X doesn't support that much RAM.

I also want to say that I was using (self compiled) Mozilla builds with the
previous patch for two months, and I cannot reproduce the problem reported in
this bug - all the test cases work fine for me (on 98 SE) with my old build and
with new 1.4.1rc Mozilla. This bug has probably to to with the model of the
graphics card used (i have a Nvidia card).
1GB of RAM is an issue on 9x, as it does support that much ram, but there is a
bug in the VCACHE driver which causes it to take up address space equivalent to
the whole physical memory. If left to its own devices, it takes up a whole GB of
kernel address space, leaving none for the rest of the OS. 

If VCACHE is manually set to a sensible size in SYSTEM.INI, 9x can handle 1GB of
RAM. See knowledge base article Q253912 for more details.
Blocks: 224532
Is this page effected by the same bug:

or is it a different bug?

Feels very slow in 1.5
Robert: no, that's bug 90198.  This bug was fixed.
Jesse:  Thanks.  Wasn't sure if it was something related to this or not.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.