Closed Bug 207796 Opened 22 years ago Closed 22 years ago

display rendering degenerates and dies

Categories

(Core Graveyard :: GFX: Win32, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 204374

People

(Reporter: ddyer, Unassigned)

Details

(Keywords: crash, stackwanted)

Attachments

(1 file)

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.
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 ?
Severity: blocker → critical
Keywords: crash, stackwanted
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)
if that helps, mark this a dup of Bug 123907.
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.
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
which URL exactly are you visiting ?
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.
this program is harmless, or compile it yourself if you're paranoid.
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; }
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.
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!
Marking NEW, since it has an analysis.
Status: UNCONFIRMED → NEW
Component: Browser-General → GFX: Win32
Ever confirmed: true
Did you look at: Bug 204374 GDI Resources are used till the UI/website displays faulty
*** This bug has been marked as a duplicate of 204374 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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: