As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
Last Comment Bug 113406 - Mac can't handle images >4095 pixels
: Mac can't handle images >4095 pixels
Status: RESOLVED FIXED
:
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
:
Mentors:
http://imgsrc.hubblesite.org/hu/db/20...
: 197646 200376 221698 230952 231704 231745 232943 (view as bug list)
Depends on:
Blocks:
  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: ---


Attachments
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 User image 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
2.open graphic from local desktop
3.watch 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 User image Terri Preston 2001-12-04 10:16:45 PST
Phil, could you attach the file please?
Comment 2 User image Phil 2001-12-04 14:30:50 PST
Created attachment 60381 [details]
jpeg used to recreate the problem.. panorama of desert camping.
Comment 3 User image Terri Preston 2001-12-04 14:49:25 PST
I see this behavior in Mac OS X 2001112806
Comment 4 User image 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 User image Stuart Parmenter 2002-02-12 00:16:53 PST
simon?  isn't this a quicktime limitation?
Comment 6 User image Stuart Parmenter 2002-02-12 00:20:40 PST
*** Bug 124767 has been marked as a duplicate of this bug. ***
Comment 7 User image 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 User image Simon Fraser 2002-02-12 10:18:49 PST
Mine
Comment 9 User image 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 User image Steve Dagley 2002-02-12 10:36:27 PST
Doh!  It's RowBytes, not RowPixels :-)
Comment 11 User image Simon Fraser 2002-04-19 14:49:07 PDT
Assigning to later milestone, since away on sabbatical.
Comment 12 User image Stuart Parmenter 2002-04-25 16:19:26 PDT
Moving bugs to new Image: GFX component
Comment 13 User image Jim Dunn 2003-03-24 09:47:31 PST
*** Bug 197646 has been marked as a duplicate of this bug. ***
Comment 14 User image Jim Dunn 2003-04-03 12:48:17 PST
*** Bug 200376 has been marked as a duplicate of this bug. ***
Comment 15 User image Simon Fraser 2003-10-09 12:33:11 PDT
*** Bug 221698 has been marked as a duplicate of this bug. ***
Comment 16 User image Simon Fraser 2004-01-15 11:17:49 PST
*** Bug 230952 has been marked as a duplicate of this bug. ***
Comment 17 User image Torben 2004-01-21 05:00:10 PST
*** Bug 231704 has been marked as a duplicate of this bug. ***
Comment 18 User image José Jeria 2004-01-21 13:06:04 PST
*** Bug 231745 has been marked as a duplicate of this bug. ***
Comment 19 User image 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
/Users/jdunn/builds/mozilla/modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cpp,
line 166
Error loading URL
http://bbs.flash8.net//attach/2003/03/07/384905-RT9Q_425763_1043203919-embed.jpg
: 80540005
Comment 20 User image 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).

  http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsImageMac.cpp#614
Comment 21 User image 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 User image 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 User image Simon Fraser 2004-02-12 23:46:52 PST
Taking back, have patch.
Comment 25 User image 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
malloc().

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 User image 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 User image Simon Fraser 2004-02-13 10:19:52 PST
This patch also contains a fix for bug 133877 (using ditherCopy)
Comment 28 User image 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 User image 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 User image Simon Fraser 2004-02-14 00:10:10 PST
Created attachment 141389 [details] [diff] [review]
As above, without the printfs.
Comment 31 User image Simon Fraser 2004-02-14 00:12:21 PST
Created attachment 141390 [details] [diff] [review]
Once more
Comment 32 User image 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 User image Simon Fraser 2004-02-16 10:15:51 PST
Bryner: any chance of another pageload run with the latest patch?
Comment 34 User image 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 User image Simon Fraser 2004-02-24 09:09:19 PST
Can I get an sr from someone?
Comment 36 User image 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 User image Simon Fraser 2004-03-01 14:37:48 PST
I'll land it tonight.
Comment 38 User image 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
done
Checking in nsImageMac.cpp;
/cvsroot/mozilla/gfx/src/mac/nsImageMac.cpp,v  <--  nsImageMac.cpp
new revision: 1.67; previous revision: 1.66
done
Checking in nsImageMac.h;
/cvsroot/mozilla/gfx/src/mac/nsImageMac.h,v  <--  nsImageMac.h
new revision: 1.35; previous revision: 1.34
done
Comment 39 User image Josh Aas 2004-03-01 21:03:42 PST
Just built Camino with the patch and it works great. Thanks!
Comment 40 User image 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 
http://axolotl.mozilla.org/graph/query.cgi?testname=pageload&tbox=monkey&autoscale=1&days=7&avg=1&showpoint=2004:03:04:20:40:46,444

Any ideas?
Comment 41 User image 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.