207796 - display rendering degenerates and dies

Status: RESOLVED DUPLICATE of bug 204374

(Core Graveyard :: GFX: Win32, defect)

Description

[Dave Dyer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: mozilla 1.4 rc 1 

this bug was also present in prevvious 1.4 releases.
After a few minutes vigorous browsing with 2 windows open, 
page rendering starts to decay - parts of the screen fail
to refresh when scrolling or paging from one page to the
next.  This effect was so severe I had to uninstall and
revert to the stable release.

Reproducible: Always

Steps to Reproduce:
1. just browse for a while.  2 windows seem to help 
2.
3.

Comment 1

[Olivier Cahagne]

1.4rc1 wfm and several other ppl on Win2k -> does not block development -> not a
blocker.
Did you properly uninstall Mozilla 1.3.1 before installing 1.4rc1 ? Possibly
using  add-ons ?

Comment 2

[Dave Dyer]

no, I just installed the new one into the same directory.
If uninstalling the prev version is a requirement, the installer
ought to tell me so.  (If correct, this makes this an installer bug)

Comment 3

[Kai Lahmann (is there, where MNG is)]

if that helps, mark this a dup of Bug 123907.

Comment 4

[Dave Dyer]

I tried reinsalling to a clean directory, and got similar 
results.  One additional clue is that when I tried to take
a screen snap of the corrupted display, the screen snapper
reported "not enough storage is available to complete the request"
.. but when I gave up and exited netscape, the screen snapper immediately
got better.   It really seems like the problem is related to memory
fragmentation caused by images.

The principal page I am browsing on is my photo album page
http://www.andromeda.com/people/ddyer/photo/albums.html
just go down the page and try all the sample albums. Use
several windows at once.

Comment 5

[Dave Dyer]

I did some additional dective work to find why "srip32" is unhappy
at the same time that mozilla's display rendering is decaying.  I found
that calls to "CreateCompatibleBitmap" with reasonable parameters are
unexpectedly failing.

I'm entertaining the theory that the immediate bug in mozilla may be
not noticing an unexpected error return of this type.  That would
be consistant with the observed behavior.

There would remain the deeper question of why CreateCompatibleBitmap
(or something like it) is failing in the first place, and in this build
of mozilla and not in 1.31

Comment 6

[Olivier Cahagne]

which URL exactly are you visiting ?

Comment 7

[Dave Dyer]

Start at http://www.andromeda.com/people/ddyer/photo/albums.html
open a second window also at http://www.andromeda.com/people/ddyer/photo/albums.html
from the second window, visit each link on the left hand column
in turn; on the "sample albums" click to visit the album (seeing
thumbnails) and on one of the thumbnailed pictures, then back
up to the starting page.   My browser starts to go wierd at
about "grovestreet.com".  There is nothing special about these
pages.

My current thinking is that the underlying problem is some kind
of resource management error in my display drivers, leading eventually
to CreateCompatibleBitmap starting to fail, which it should never
do.  My machine is a new dell running win2k with 512m of physical
memory, so it shouldn't be "out" of any common resource in such a
short expetiment.  However, mozilla's part in this is that it doesn't
notice the problem and so looks like it is broken itself.

Comment 8

[Dave Dyer]

Attachment: compiled version of the quoted bitmap bomber program

this program is harmless, or compile it yourself if you're paranoid.

Comment 9

[Dave Dyer]

More evidence.  The following program fails at bitmap 85 on my win2k 
machine, which has a hot graphics card (geforce4 mx 420) and 512m 
main memory.  The same program runs all the way to 100 on my old nt machine
which had an vanilla graphics card. 

My guess is that win2k is treating "screen compatible" bitmaps as a limited
resource, and the new version of mozilla is using them for general storage
of cached images.

// See how many screen bitmaps can be allocated 
//

#include "stdafx.h"
#include "windows.h"

#define DIMW 1024
#define DIMH 1024
#define NUMBER 100

int main(int argc, char* argv[])
{
	HDC	hdc = GetDC(0);
	HDC hMem = CreateCompatibleDC(hdc);
	HANDLE bitmaps[NUMBER];
	long i;

	printf("Hello World!\n");

	for(i=0;i<NUMBER;i++)
	{	bitmaps[i]=CreateCompatibleBitmap(hMem,DIMW,DIMH);
		printf("Bitmap %d = %x\n",i,bitmaps[i]);
		if(bitmaps[i]==0) { break; }
	}
	for(; i>=0; i--)
	{	DeleteObject(bitmaps[i]);
	}
	DeleteDC(hMem);
	DeleteDC(hdc);
	printf("Done\n");
	return 0;
}

Comment 10

[Dave Dyer]

Final word (ha, you wish).  Google conversations seem to universally
recommend CreateDIBSection rather than CreateCompatibleBitmap; CreateDIBSection
is limited only by available memoey, whereas CreateCompatibleBitmap is subject
to arbitray and ill defined limitations on size and number of bitmaps.

Comment 11

[Dave Dyer]

One more comment.  This problem is not new to 1.4, it also occurs in 1.3.1
but with much less frequency.  When this problem has occurred, lots of things
stop working; I can't take screen snaps, my thumbmailer won't show thumbnails,
and launching adobe photoshop crashes.  Clearly, a bad state of affairs.

I'm fairly certain that the root problem is that everyone is treating device
dependant bitmaps as an inexhaustable resource. whereas the video drivers
on my system are treating it as a finite resouce.  Perhaps this is wrong, but
there are probably a few million computers out there with my video board, so it
is likely to remain a problem.

Mozilla is unneccarily consuming a limited resource.  Just use DIBs!

Comment 12

[Olivier Cahagne]

Marking NEW, since it has an analysis.

Comment 13

[Hermann Schwab]

Did you look at:
Bug 204374 GDI Resources are used till the UI/website displays faulty

Comment 14

[Dave Dyer]

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