Last Comment Bug 113406 - Mac can't handle images >4095 pixels
: Mac can't handle images >4095 pixels
Product: Core Graveyard
Classification: Graveyard
Component: Image: Painting (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- major with 1 vote (vote)
: mozilla1.5beta
Assigned To: Simon Fraser
: Terri Preston
: 197646 200376 221698 230952 231704 231745 232943 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2001-12-04 01:03 PST by Phil
Modified: 2011-08-05 21:15 PDT (History)
16 users (show)
asa: blocking1.7a-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

jpeg used to recreate the problem.. panorama of desert camping. (366.25 KB, image/jpeg)
2001-12-04 14:30 PST, Phil
no flags Details
nsImageMac patch to use GWorlds for images (53.42 KB, patch)
2004-02-12 23:49 PST, Simon Fraser
no flags Details | Diff | Splinter Review
Added use of cached GDHandle (54.92 KB, patch)
2004-02-13 23:46 PST, Simon Fraser
no flags Details | Diff | Splinter Review
As above, without the printfs. (54.41 KB, patch)
2004-02-14 00:10 PST, Simon Fraser
no flags Details | Diff | Splinter Review
Once more (54.33 KB, patch)
2004-02-14 00:12 PST, Simon Fraser
ccarlen: review+
bryner: superreview+
Details | Diff | Splinter Review

Description Phil 2001-12-04 01:03:50 PST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112020

when attempting to open a jpeg image from my local disk, mozilla will not
display the image at all, although it will expand the viewable pane as if it has
knowledge of the size of graphic it is working with.

the jpeg is approximately 400k, and is 6376x424.

good news is that IE under Mac OS X doesn't display this image properly either
-- it crops it at approximately half way across.

Reproducible: Always
Steps to Reproduce:
1.install mozilla graphic from local desktop nothing happen

Actual Results:  the browser window opened with the correct image width
information, but the graphic does not display, and there is no broken image icon.

Expected Results:  mozilla should have displayed the graphic, darnit.

nada.  I think the above outlines the problem perfectly fine.
Comment 1 Terri Preston 2001-12-04 10:16:45 PST
Phil, could you attach the file please?
Comment 2 Phil 2001-12-04 14:30:50 PST
Created attachment 60381 [details]
jpeg used to recreate the problem.. panorama of desert camping.
Comment 3 Terri Preston 2001-12-04 14:49:25 PST
I see this behavior in Mac OS X 2001112806
Comment 4 Steve Dagley 2002-02-10 15:55:04 PST
Looks like we do not display any JPEG image if it is >4095 pixels wide on the
Mac under either Mac OS 9 or X.  The Windows build of Mozilla 0.9.8 does not
exhibit this problem.  This may not be a common problem for pr0n but for
scientific images and panoramic photos it is so clearing the TFV of future.
Comment 5 Stuart Parmenter 2002-02-12 00:16:53 PST
simon?  isn't this a quicktime limitation?
Comment 6 Stuart Parmenter 2002-02-12 00:20:40 PST
*** Bug 124767 has been marked as a duplicate of this bug. ***
Comment 7 Steve Dagley 2002-02-12 09:12:12 PST
No, this isn't a QuickTime limitation.  And AFIAK we don't use QuickTime for 
image decoding (yet).  Perhaps you meant QuickDraw?  Again, not a limitation of 
QuickDraw.  It's our code that's whiffing here.
Comment 8 Simon Fraser 2002-02-12 10:18:49 PST
Comment 9 Simon Fraser 2002-02-12 10:24:52 PST
It's a QuickDraw limitation that we can't easily work around. The only solution
would be to render large images in pieces.
Comment 10 Steve Dagley 2002-02-12 10:36:27 PST
Doh!  It's RowBytes, not RowPixels :-)
Comment 11 Simon Fraser 2002-04-19 14:49:07 PDT
Assigning to later milestone, since away on sabbatical.
Comment 12 Stuart Parmenter 2002-04-25 16:19:26 PDT
Moving bugs to new Image: GFX component
Comment 13 Jim Dunn 2003-03-24 09:47:31 PST
*** Bug 197646 has been marked as a duplicate of this bug. ***
Comment 14 Jim Dunn 2003-04-03 12:48:17 PST
*** Bug 200376 has been marked as a duplicate of this bug. ***
Comment 15 Simon Fraser 2003-10-09 12:33:11 PDT
*** Bug 221698 has been marked as a duplicate of this bug. ***
Comment 16 Simon Fraser 2004-01-15 11:17:49 PST
*** Bug 230952 has been marked as a duplicate of this bug. ***
Comment 17 Torben 2004-01-21 05:00:10 PST
*** Bug 231704 has been marked as a duplicate of this bug. ***
Comment 18 José Jeria 2004-01-21 13:06:04 PST
*** Bug 231745 has been marked as a duplicate of this bug. ***
Comment 19 Asa Dotzler [:asa] 2004-01-27 14:35:58 PST
From a duplicate report: 

###!!! ASSERTION: PixMap too big for QuickDraw: '0', file
/Users/jdunn/builds/mozilla/gfx/src/mac/nsImageMac.cpp, line 616
Break: at file /Users/jdunn/builds/mozilla/gfx/src/mac/nsImageMac.cpp, line 616
WARNING: Never finished decoding the JPEG., file
line 166
Error loading URL
: 80540005
Comment 20 Asa Dotzler [:asa] 2004-01-27 14:36:56 PST
tor says in one of the dupes:

mac gfx is throwing out images that have more than 16384 bytes in a row
(width 4096).
Comment 21 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-03 06:36:45 PST
*** Bug 232943 has been marked as a duplicate of this bug. ***
Comment 22 Asa Dotzler [:asa] 2004-02-09 15:14:55 PST
Not going to block 1.7alpha for this. Simon, bryner says that you described a
possible simpler approach than rewriting Mac GFX to use the new quartz APIs.
Comment 24 Simon Fraser 2004-02-12 23:46:52 PST
Taking back, have patch.
Comment 25 Simon Fraser 2004-02-12 23:49:05 PST
Created attachment 141300 [details] [diff] [review]
nsImageMac patch to use GWorlds for images

This patch is a rewrite of nsImage mac to use GWorlds, created via
NewGWorldFromPtr(), for images and masks. Image bits are allocated via

There are extensive changes to deal with the draw to icon stuff (which isn't
called, as far as I can tell, so is untested).

This needs some performance evaluation, so before/after pageload numbers would
be good.
Comment 26 Simon Fraser 2004-02-12 23:51:32 PST
With this patch the attached image displays fine (as do the Mars rover images).
Comment 27 Simon Fraser 2004-02-13 10:19:52 PST
This patch also contains a fix for bug 133877 (using ditherCopy)
Comment 28 Kathleen Brade 2004-02-13 10:45:01 PST
I skimmed the patch and it looks fine to me.  I applied the patch in my mozilla
tree and it looks fine.  I can see the image in the URL field above.  Simon is
going to check for memory leaks.
Comment 29 Simon Fraser 2004-02-13 23:46:46 PST
Created attachment 141383 [details] [diff] [review]
Added use of cached GDHandle

This patch might be a tad faster.
Comment 30 Simon Fraser 2004-02-14 00:10:10 PST
Created attachment 141389 [details] [diff] [review]
As above, without the printfs.
Comment 31 Simon Fraser 2004-02-14 00:12:21 PST
Created attachment 141390 [details] [diff] [review]
Once more
Comment 32 Conrad Carlen (not reading bugmail) 2004-02-16 08:09:22 PST
Comment on attachment 141390 [details] [diff] [review]
Once more

Patch looks good, works in my testing. r=ccarlen.
Comment 33 Simon Fraser 2004-02-16 10:15:51 PST
Bryner: any chance of another pageload run with the latest patch?
Comment 34 Simon Fraser 2004-02-20 21:49:44 PST
Comment on attachment 141390 [details] [diff] [review]
Once more

Bryner said that this latest patch doesn't slow pageload at all. So it's good
to go.
Comment 35 Simon Fraser 2004-02-24 09:09:19 PST
Can I get an sr from someone?
Comment 36 Asa Dotzler [:asa] 2004-03-01 14:32:58 PST
Simon, it looks like this has the r and sr needed. Can you land it on the trunk
so it can make the Beta?
Comment 37 Simon Fraser 2004-03-01 14:37:48 PST
I'll land it tonight.
Comment 38 Simon Fraser 2004-03-01 20:01:27 PST
Checked in:

Checking in nsIImageMac.h;
/cvsroot/mozilla/gfx/src/mac/nsIImageMac.h,v  <--  nsIImageMac.h
new revision: 1.6; previous revision: 1.5
Checking in nsImageMac.cpp;
/cvsroot/mozilla/gfx/src/mac/nsImageMac.cpp,v  <--  nsImageMac.cpp
new revision: 1.67; previous revision: 1.66
Checking in nsImageMac.h;
/cvsroot/mozilla/gfx/src/mac/nsImageMac.h,v  <--  nsImageMac.h
new revision: 1.35; previous revision: 1.34
Comment 39 Josh Aas 2004-03-01 21:03:42 PST
Just built Camino with the patch and it works great. Thanks!
Comment 40 Benjamin Smedberg [:bsmedberg] 2004-03-04 21:12:19 PST
This bug appears to have regressed monkey Tp by 3.4% (it looks like a mac-only
regression), see,444

Any ideas?
Comment 41 Simon Fraser 2004-03-04 21:17:46 PST
This was expected, and, in discussions with Asa at Mozilla, was deemed a
worthwhile tradeoff.

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