Closed Bug 55940 Opened 24 years ago Closed 23 years ago

large view-image blanked out with low memory

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: orion, Assigned: pavlov)

References

(
URL
)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001007
BuildID:    2000100720

 the picture is displayed while loading but as soon as the picture has finished
being transferred it shows nothing

Reproducible: Always
Steps to Reproduce:
just let the browser load the picture and wait for it to finish

Actual Results:  nothing

Expected Results:  just displayed the picture
Might be something to do with the large size of the image (2400 x 3000).
win98 2000100720, worksforme.  Are you still seeing this?
2000100908 win98 WFM
win98 2000100908 worksforme as well
worksforme with win32 mozilla trunk build 101004
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I'm still seeing this in Build 2000101020 in WinNT SP5 with 64MB RAM at 1024x768x24.
2000101104 stills worksforme
I'm still seeing this on WinNT.
What can I run to analyse what is happening?  I don't have any MS C++
Development tools on my machine.

over to imagelib for further investigation.
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → ImageLib
Resolution: WORKSFORME → ---
reassign to default owner.
Assignee: asa → pnunn
QA Contact: doronr → tpreston
wfm on win2k trunk build 2000110120.
But while loading my Mozilla is very very slow.
My Athlon 600 seem to be a C64 :-)
I still see this problem with Build 2000110220 in WinNT.

perhaps a problem with low memory ?
The reporter have "only" 64MB RAM and NT.
I can´t see this with WIN2K but I have 196MB.

Reporter: Can you Do you delete your cache files (Profile/Cache) and the 
mozregistry.dat ?

I should point out that I'm not the reporter but I can see the Bug.
At weekends I use a Linux box with 32MB ram, and I don't see the problem here,
although the image does take 35-40 minutes to load!
On Monday I'll delete the cache and mozregistry.dat when I use WinNT next and
try loading the image.


I deleted mozregistry.dat and the Cache directory and started Mozilla build
2000110520 in WinNT.
I went to this page and clicked on the url.  The picture loaded and blanked out
as soon as it had completed loading.
I can still see this Bug.

setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Works For Me in Build 2000111220 in WinNT, although the image appears to be
downloaded fully before any of it is displayed, rather than been incrementally
displayed as the file is downloaded.

Picture blanks out in Build 2000111404 in WinNT.
The picture is displayed as the image is loaded, but blanks out when the image
is fully downloaded.


looks fine to me on my NT build from 11-10.
Let me update my tree and see if I can duplicate the
Mystery of the Disappearing Image.
-p
Status: NEW → ASSIGNED
I can see the disappearing image problem on a 
win95 machine with 48M ram.
-p
Summary: picture blanks out → large view-image blanked out with low memory
Blocks: 61480
*** Bug 62534 has been marked as a duplicate of this bug. ***
Isn't this another dup of bug 9922?
*** Bug 62602 has been marked as a duplicate of this bug. ***
Win98SE Mozilla 0.6

Problem seen here from time to time, not 100% reproducible. Only seen here on a 
dialup connection, never seen on fast connection, ie., T1, Cable, DSL. Size of 
image(s) does not seem to matter, happens with large or small images as well.
Image problem exists for me.

Win98/PIII-600(256MB)
Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 
Always reproducible.

A large percentage of our image files are acting exactly as described. The file 
will download as part of a simple HTML document and, upon completion, remain 
viewable for about 1/2 second, then disappear. The image can be saved and re-
loaded directly from disk with the same effect (not HTML related or download-
bandwidth related). No problems in IE5 or Netscape 4.75.

The page layout remains as if the image was there. In fact, you can right-click 
the (blank) image and save it, etc.

Typical files are around 250KB and 2100 x 2100 px.
After further investigation,

1. The image rendering problem exists whether or not Java/Javascript is enabled 
(see, I read the ImageLib bug FAQ!)
2. I take back what I said about it not being an HTML problem. If I explicitly 
set the IMG tag to have WIDTH <= 2044 and HEIGHT <= 2043, the image renders 
fine - always reproducible.  Budging either of these values up 1 results in the 
lost image (even if you lower the other number by any amount) - always 
reproducible.  This works successfully for all of our image library (so far).  
Deliberately NOT setting the WIDTH and HEIGHT values also results in the 
disappearing image (as in our original code).  That's probably why saving an 
image to disk still doesn't render properly - it appears that ImageLib just 
can't handle images of greater size (can anyone refute this?).

At least our customers can see our images now, but this workaround incorporates 
image scaling, which wouldn't be cool for someone pushing out a 4k x 4k.

Again, this is a PIII-600 with 256MB RAM and an ATI 3D Rage Pro displaying 32-
bit color at 1024 x 768.
mark:
super info. this bug may be related to 61597, though
the symptoms are different enought to keep the bug "unduped"
for now.
much thanks for the info.
-p
One more thing that may be of some help.  Setting the IMG tag WIDTH and/or 
HEIGHT values to <I>percentages</I> still does not work, and the image 
disappears anyway (even if the percentage brings the dimensions well within the 
apparent maximums I discussed earlier). 

If you dynamically generate web pages with CGI and don't want smaller images 
enlarged to hard coded dimensions, Perl's user_agent and Image::Size module can 
help you work around this issue.
Target Milestone: --- → mozilla1.0
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
Keywords: qawanted
I believe this was fixed with the new imagelib, tested on network and over modem 
w98 build 2001042504 closing fixed, reporter please reopen if you are still 
experiencing this
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.