Last Comment Bug 184933 - loading lots of images makes moz forget to repaint everything
: loading lots of images makes moz forget to repaint everything
Status: VERIFIED DUPLICATE of bug 204374
:
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: x86 All
: P2 major with 5 votes (vote)
: Future
Assigned To: Kevin McCluskey (gone)
: Hixie (not reading bugmail)
:
Mentors:
: 183007 187526 187722 192362 211455 226234 228436 (view as bug list)
Depends on:
Blocks: 157256
  Show dependency treegraph
 
Reported: 2002-12-11 17:04 PST by Jesse Ruderman
Modified: 2012-06-04 19:33 PDT (History)
25 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Jesse Ruderman 2002-12-11 17:04:19 PST
Steps to reproduce:
1. Drag the "linked images" bookmarklet from
http://www.squarefree.com/bookmarklets/pagelinks.html to your bookmarks toolbar.
2. Go to http://pantransit.reptiles.org/images/nsorted/anime/azumanga-daioh/.
3. Use the linked images bookmarklet.
4. Wait for all the images to load into the new window.  If you want, read them
while they load.
5. Close the new window.
6. Use the linked images bookmarklet again, letting Mozilla load the images from
the cache.

Result: Mozilla gets into a state where it forgets to draw many things.  This
affects all Mozilla windows.

Not drawn:
  loading a new page
  switching from another application that covered the window
  scrolling a page at a time (click in scrollbar elevator, pgdn)
Drawn:
  chrome buttons, but only when I mouse over them
  scrolling in small increments (mouse wheel, arrow keys, drag scrollbar thumb)

I hit this bug a lot while surfing porn and using the "linked images"
bookmarklet, but this is the first time I've been able to reproduce the bug. 
(The URL above is not porn.)  Closing the window that contains all the images
usually (always?) makes the problem go away.

I suspect that something is going wrong at the OS level.  If I trigger this bug
using Phoenix, then Mozilla windows also forget to redraw.  But other apps
(winamp, mIRC, notepad, IE) don't have any trouble remembering to draw.

I'm using Windows XP.  Display Properties > Advanced > Adapter reports that I am
using "16MB ATI Rage 128 Ultra", which has chip type "RAGE128 PRO II, (AGP 4X/PCI)".

Related: bug 157256, "Repainting of most widgets is not happening under Win98
after a period of time".  The symptoms are the same, but bug 157256 doesn't have
steps to reproduce.

Reproducibility: 0/2 when uncached, 5/5 when cached.  Tested in both Phoenix 0.5
and Mozilla 12/07.
Comment 1 Hixie (not reading bugmail) 2002-12-11 17:54:08 PST
I also see this, using build 2002120604 on Windows 2000, with a GeForce2Go.

It also happens to me when browsing lots of images (e.g. when surfing porn), and
specifically happens a lot more when the images are cached (e.g. when surfing
freenet porn). It affects all open Mozilla windows at the same time. Closing
tabs after a while can stop it happening, but it can just start up again as well
(presumably when the more cached images are viewed?).

Basically, the windows stop painting. Reflow has no effect. Menus don't render.
Scrolling with the page up/down keys does nothing. Slowly moving the scrollbar
(if you can hit it) repaints newly exposed bits of the page, but scrolling fast
has no visible effect. Hovering over elements of the UI that have :hover rules
causes them to repaint. Dragging the window slowly off-screen and back causes
exposed bits of the window to repaint. Dragging another window over the top does
not. Other applications are totally unaffected.
Comment 2 Jesse Ruderman 2003-01-06 02:34:37 PST
*** Bug 187722 has been marked as a duplicate of this bug. ***
Comment 3 Tom Carter 2003-01-06 07:25:50 PST
For me, this is reproducible 100% of the time using the procedure described (and
many others, unfortunately).

I am using: Windows 2000 Server, [Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.2.1) Gecko/20021130]
Comment 4 Hixie (not reading bugmail) 2003-01-28 03:06:19 PST
This is really disconcerting. I haven't heard any non-Windows reports of this
happening, so my guess is that we are simply leaking some system object,
probably GDI, when we view images, probably specifically cached ones.

Anyone have any ideas?
Comment 5 Arthur 2003-01-28 03:25:04 PST
Confirming exactly the same behaviour on linux 2003012722. Something similar
happens if you open a lot of image links in tabs. Some of them stay grey and
can't be closed anymore. Weird. Happend to me for example when serching for
train bridges with googles image search and opening the picturelinks in new tabs.
Comment 6 R.K.Aa. 2003-02-07 22:57:42 PST
*** Bug 192362 has been marked as a duplicate of this bug. ***
Comment 7 R.K.Aa. 2003-02-07 22:58:48 PST
*** Bug 187526 has been marked as a duplicate of this bug. ***
Comment 8 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2003-02-07 23:31:04 PST
Confirmed in moz 1.3a, and 1.0.2.

I attempted to take a screenshot using printscreen and MSPaint.  Earlier today
it was giving me an error, now it did what MS Word did earlier: give me an ugly
black & white image.

http://ctho9305.res.cmu.edu/pics/moz.PNG (the left part of the browser is
showing http://forums.anandtech.com/messageview.cfm?catid=38&threadid=971379,
the rest is showing this page.  I dragged winamp over the part showing anandtech
to get it to redraw itself)
Comment 9 Steve Chapel 2003-02-22 09:52:49 PST
Possibly a dupe of bug 133132.
Comment 10 Jim Dunn 2003-07-15 07:51:59 PDT
With my patch for bug 205893 I still see the problem, UNLESS
I set my disk cache to 150Mb (100Mb doesn't work).  Please don't
ask me why this helps, it just does.  I also tried just
not using GDI resources for images (in nsImageWin :: Optimize
just return NS_OK;) and the problem goes away (this is with 
my default 50Mb cache size).
Comment 11 Asa Dotzler [:asa] 2003-07-27 19:12:33 PDT
mozilla1.4 shipped. unsetting blocking1.4 request.
Comment 12 Lewis Jardine 2003-08-04 15:46:28 PDT
Jim, do you see this problem under NT and 9x with patch 127547 , or just under
9x?  9x does not have a maximum number of bitmaps, rather a maximum memory
capacity the bitmaps must fit into. Might it be the case that there are less
than BITMAP_CACHE_SIZE handled bitmaps, but their total size is greater than the
GDI capacity, so the GDI is full but the cache isn't getting emptied?

Presumably OS should be set to 'windows 95' for this bug?
Comment 13 Jim Dunn 2003-08-04 15:59:24 PDT
No this bug, I see on both 98 & win2000 with and without patch 127547 (bug 205893).
Comment 14 Jim Dunn 2003-09-10 06:59:44 PDT
This now appears to be fixed based on the patch for bug 216430
(which fixed the regression caused by bug 205893
Comment 15 Jesse Ruderman 2003-09-20 21:34:57 PDT
I haven't been hitting this bug lately.  The URL in comment 0 has changed and no
longer screws up Phoenix 0.5, so I can't be sure that this bug was fixed.  I
think it would be reasonable to mark this as a dup of bug 205893.
Comment 16 Nick Konstadoglou 2003-10-10 07:57:35 PDT
It still exists with firebird 0.7+ win98. I think it has to do with bug 204374,
or at least some other form of memory leak.
Comment 17 Shoshannah Forbes 2003-10-23 09:21:18 PDT
I am still seeing this with 1.5 and windows 2003. Very very annoying.
Comment 18 Harry Sufehmi 2003-11-23 01:56:52 PST
*** Bug 226234 has been marked as a duplicate of this bug. ***
Comment 19 alanjstr 2003-12-23 13:42:35 PST
*** Bug 228436 has been marked as a duplicate of this bug. ***
Comment 20 Jesse Ruderman 2004-01-31 23:53:33 PST
*** Bug 211455 has been marked as a duplicate of this bug. ***
Comment 21 Jesse Ruderman 2004-02-23 00:01:20 PST

*** This bug has been marked as a duplicate of 204374 ***
Comment 22 Henrik Skupin (:whimboo) [away 09/30 - 10/06] 2004-02-23 00:16:22 PST
verified.
Comment 23 Asa Dotzler [:asa] 2004-03-09 14:02:14 PST
*** Bug 183007 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.