101018 - (LargeGIF) very large images do not draw

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Jon Smirl]

I tried loading a 4MB PNG file containing a graph of Mozilla's dependencies. I 
used File/Open to directly open the file.

Failure code is:
Enabling Quirk StyleSheet
Document file:///C:/cvs/mozilla/moz.png loaded successfully
Disabling Quirk StyleSheet
Enabling Quirk StyleSheet
Error reading file C:\cvs\mozilla\moz.png
Error loading URL file:///C:/cvs/mozilla/moz.png : 80004005 (NS_ERROR_FAILURE)

First try seems to have loaded the file. The scroll bars were set to the right 
size but nothing was visible. Second try failed when I used the reload button.

IE6 loaded the file without problem.

I doubt if you want me to attach a 4MB file to a bug.
If you want it send me an email.

Comment 1

[Terri Preston]

http://bugzilla.mozilla.org/show_bug.cgi?id=101018

Comment 2

[Daniel Steinberger]

confirming this with a (for this purpose generated) png. does not depend on PNG
anyhow. it won't load the same image as JPEG either. i also put it into an
html-file with <img... but strangely once it drawed a bit of the image, but when
i started scrolling, the image scrolled of screen, and didn't return on
scrolling back. wasn't able to reproduce this. WinXP/2002022103
my image was 8000x6000 pixel and filled with some random lines and a
full-hue-gradient.

my conclusion: change summary from
  "Loading 4MB PNG file fails"
to
  "very large images do not draw"

to clearyfy that it does not depend on PNGs. hm.. any other thoughts:

* could it be, that this is a feature(tm), to prevent loading too large images? 
* should this maybe become OS/All?
* this is really a 'future' bug!

Comment 3

[galilkalasch]

Confirmed it with a 2.2 MB jpg (3000x1955)
http://www.defenselink.mil/photos/Sep2001/010914-F-8006R-002.jpg
under 2002031104 and Win98. It is always reproducable.

The portin of the pic that is in the window is at first displayed properly but
scrolling gives only the browser's background color, even when I return to the
original viewport. A reload gives only the empty background.

Comment 4

[galilkalasch]

2002031008/Linux displays and scrolls
http://www.defenselink.mil/photos/Sep2001/010914-F-8006R-002.jpg without the
above mentioned problem.

Comment 5

[ArronM (:paper)]

2002050208/Win2k
http://www.defenselink.mil/photos/Sep2001/010914-F-8006R-002.jpg 
WFM, tried scrolling, reloading

Comment 6

[Mike]

I seem to be getting this problem with the image at
http://astronomy.wellington.net.nz/images/gallery/Moss-Paul/020512-misc/big-3Amoon.jpg
under 2002041711/Win98.  Judging by activity on the status bar the whole process
of loading it seems to happen and the scrollbars are there. It just doesn't draw
anything.

The image is 3096x2036 but it's only 85k, so I guess file size isn't all of the
problem.

Comment 7

[Lorenzo Colitti]

I am unable to reproduce the bug on any of the other images, but I am seeing it
on WinME and Win98 with this one, which is 4636x4136:

http://www.caida.org/outreach/resources/learn/ipv4space/images/map.gif

Changing URL to reflect this. What I see is consistent with comment #3: 

> The portin of the pic that is in the window is at first displayed
> properly but scrolling gives only the browser's background color, even
> when I return to the original viewport.

However, reload works.

Comment 8

[ArronM (:paper)]

stealing bug & CCing pav

Comment 9

[ArronM (:paper)]

Attachment: Stop Win95/98/ME from using DDB optimization

As MSDN says: 
"Windows 95/98/Me: The created bitmap cannot exceed 16MB in size."

When the decoder calls SetMutable(PR_FALSE), it calls nsIImage::Optimize(). 
nsImageWin::Optimize sets a flag so that a DDB will be created later for the
image.

This patch prevents the flag from being set if Win95/98/ME and image is > 16M

Comment 10

[Lorenzo Colitti]

+  if (gIsWin95 && mSizeImage > 16000000) 

Paper, shouldn't that be 16777216 or 0x1000000?

Stupid bashing aside, kudos for the quick turnaround. :-)

Unfortunately I'm not set up for building on Win32, so I can't test it. Can you
provide a binary?

Comment 11

[ArronM (:paper)]

hmm, 0x1000000 should work, but I'll have to test an image that uncompresses to
> 16000000 && < 0x1000000.  I reason I used 16 million was because I copied it
from the unused gfxImageFrameWin.
http://lxr.mozilla.org/seamonkey/source/gfx2/src/windows/gfxImageFrameWin.cpp#602

I'll look on the net to see if there was a reason why 16 million was chosen
instead 16MB.  Perhaps there's a known issue or something.

I've put up http://animecity.nu/mozilla/gkgfxwin.dll 
I can't guarantee your mozilla will even run with this dll since I don't know
what my code's been through.  But if you feel brave, you can try it. :)

Comment 12

[Lorenzo Colitti]

I tried it, but my Moz 1.0 RC3 hangs on startup. So we'll have to test it some
other way. :)

Comment 13

[Lorenzo Colitti]

*** Bug 147398 has been marked as a duplicate of this bug. ***

Comment 14

[Wesha]

*** Bug 147398 has been marked as a duplicate of this bug. ***

Comment 15

[ArronM (:paper)]

Comment on attachment 86288 [details] [diff] [review]
Stop Win95/98/ME from using DDB optimization

needs a bit more checking.. will hopefully post new patch tommorrow

Comment 16

[ArronM (:paper)]

Attachment: DDB optimization checking

I've done many tests and it seems the "16MB limit" is actually 0xFF0000 (on
Win98 anyway).	Anything above that, and mHBitmap gets set to 0.

I also added HBitmap-creation validation checking to the code that didn't have
it already.

Comment 17

[ArronM (:paper)]

Also of note is that animated gifs with individual frames bigger than 16MB will
not animate correctly on Win95/98/ME.  One of the side effects of fixing Bug
143830 will be that this limitation will be removed.  Although, one would
question why anyone would have a 16MB gif frame. 

Comment 18

[Stuart Parmenter]

Comment on attachment 86466 [details] [diff] [review]
DDB optimization checking

r=pavlov

Comment 19

[ArronM (:paper)]

tor, can you sr=?

Comment 20

[tor]

Comment on attachment 86466 [details] [diff] [review]
DDB optimization checking

>-  static PRBool gIsWinNT;
>+  static PRBool gIsWinNT;  // Win NT/2K/XP/.NET Server
>+  static PRBool gIsWin95;  // Win 95/98/ME

Why do we need two flags to store one bit of information?

>@@ -391,10 +408,11 @@
>        } else {
>          mHBitmap = ::CreateDIBitmap(TheHDC,mBHead,CBM_INIT,mImageBits,(LPBITMAPINFO)mBHead,
>                   256==mNumPaletteColors?DIB_PAL_COLORS:DIB_RGB_COLORS);
>+         mIsOptimized = mHBitmap != 0;

A set of parens would be a nice touch.

Comment 21

[ArronM (:paper)]

Attachment: DDB optimization checking

> Why do we need two flags to store one bit of information?
After looking into it further, gIsWinNT isn't even used.  Anyway, I replaced
them both with gPlatform.

> A set of parens would be a nice touch.
Done

Comment 22

[tor]

Comment on attachment 86857 [details] [diff] [review]
DDB optimization checking

sr=tor

Comment 23

[Stuart Parmenter]

Comment on attachment 86857 [details] [diff] [review]
DDB optimization checking

r=pavlov

Comment 24

[Wesha]

Bug still present in 2002060804 / win98

Comment 25

[Stuart Parmenter]

*** Bug 148510 has been marked as a duplicate of this bug. ***

Comment 26

[Stuart Parmenter]

checked in for paper

Comment 27

[Shark Daddy (Jonathan L.)]

*** Bug 148867 has been marked as a duplicate of this bug. ***

Comment 28

[Simón Medrano]

While trying to view http://www.fabiolrs.hpg.ig.com.br/spamdemicmap.gif the
browser displays the partially downloaded image. After the image is completely
downloaded, mozilla does not redraw the scrolled-out areas.
The same for http://www.caida.org/outreach/resources/learn/ipv4space/images/map.gif
I'm using Mozilla v1.1a (2002061104) on Win98 SE.

Comment 29

[Wesha]

*** Bug 159718 has been marked as a duplicate of this bug. ***

Comment 30

[Daniel Wang]

*** Bug 140548 has been marked as a duplicate of this bug. ***