Closed Bug 225977 Opened 19 years ago Closed 19 years ago

Painting problems with page that has large number of images - resource leak?


(Core Graveyard :: GFX: Win32, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: wd, Unassigned)




User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028

*** Note:  The URL for this bug is NOT SAFE FOR WORK ***

The URL for this bug has a page that has over 100 images in an XHTML web page. 
When I visit the page, mozilla no longer properly paints properly.  (similar to
bug 204374 , but I couldn't see any abnormal GDI usage myself)

Reproducible: Always

Steps to Reproduce:
1.Go to    (NSFW) on another tab

Actual Results:  
The content area for the new tab isn't painted properly.  (artifacts of original
page).   Also, the other areas of Mozilla such as menus, etc. do not paint right

Expected Results:  
no problems.

I have tried the workaround listed in bug 204374 (setting memory cache), but
that has no effect whatsoever.   The GDI Resource tool listed in that bug shows
no abnormal GDI usage when that page is open either.

Mozilla must be closed for it to function properly again.
Providing a better URL (Safe for work, etc.):

This website has over 400 pictures. When opened in mozilla, the GUI refuses to
properly redraw and only by closing the tab can mozilla be used. (All other tabs
are not drawn correctly with this url opened in any tab.) It is impossible to
scroll once the pictures are all displayed.
This URL will open properly in IE, but not mozilla. IE will increase the memory
usage to 200Megs when opening this URL while mozilla stops at about 70Megs.

Reproducible: Always on Windows
Tested on: Windows XP
Tested with: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030804

Works on: Linux (Gentoo)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031119
Changing URL for bug to a SFW one.

I've compared GDI usage for IE and Mozilla/Firebird and what's interesting here
is that IE actually uses *more* resources than Mozilla, yet it causes no
painting problems.

          Total   DC  Region   Bitmap  Pallette  Font  Brush  Other
Mozilla:    301    3      24      220         5    12     37      0
IE:         558   23       4      487         3    22     19      0

The other thing I noticed is that as the page is loading, most other apps seem
to work fine, painting-wise.  (Eudora, AIM, Windows Explorer, etc...).   But the
programs that are immediately affected are Thunderbird and Firebird  (Or
Thunderbird and Mozilla if I'm loading the page in Firebird)
*** Bug 226435 has been marked as a duplicate of this bug. ***
*** Bug 227245 has been marked as a duplicate of this bug. ***
I also tested with this web page ( reported in
bug 211377 (probably a duplicate). It works fine for a while, but the system
eventually becomes slow, and the windows are not repainted properly. However, if
I close that window, Mozilla is working fine again, except that the memory
doesn't come down to the previous levels (the difference is about 40MB). I guess
it's a memory leak somewhere.

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040117 
I'm getting the same behavior in Windows Server 2003 with 2.6gb of memory 
(74200 used by Mozilla, not a lot really).

URL (somethingawful account required):

Almost any big image thread will trigger the behavior.  

Note that it is NOT impossible to scroll.  It is only impossible to scroll 
using the keyboard (arrows or pgup/pgdown).  Scrolling still works when using 
the mouse to drag the scrollbar or using the scrollwheel on the mouse.
*** Bug 178105 has been marked as a duplicate of this bug. ***
*** Bug 233873 has been marked as a duplicate of this bug. ***
there seems to be dups of this also in bug 193011
This bug is probably the same as bug 204374

A page which shows this bug immediately in mozilla 1.6 is

In this case, scrolling with the mouse/scrollbar doesn't
work either.   AND note that it works fine with mozilla 1.3.1
(which consequenly seems destined to be my default browser
I think this bug is a dup of bug 213391. Each image is stored in the cache even
if the is cache is already filled. None of the already loaded images could be
removed from the because they are in use by the page self. You can check this by
entering about:cache in an other tab after (or when) loading the page.
In bug 204374 comment 340 I mentioned that the cache workaround will not work in
some cases (like this one).

*** This bug has been marked as a duplicate of 213391 ***

*** This bug has been marked as a duplicate of 213391 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
V. Dupe.
The patch for bug 213391 fixes this problem.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.