113406 - Mac can't handle images >4095 pixels

Status: RESOLVED FIXED

(Core Graveyard :: Image: Painting, defect)

Description

[Phil]

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

[Terri Preston]

Phil, could you attach the file please?

Comment 2

[Phil]

Attachment: jpeg used to recreate the problem.. panorama of desert camping.

Comment 3

[Terri Preston]

I see this behavior in Mac OS X 2001112806

Comment 4

[Steve Dagley]

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]

simon?  isn't this a quicktime limitation?

Comment 6

[Stuart Parmenter]

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

Comment 7

[Steve Dagley]

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 [no longer active]]

Mine

Comment 9

[Simon Fraser [no longer active]]

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]

Doh!  It's RowBytes, not RowPixels :-)

Comment 11

[Simon Fraser [no longer active]]

Assigning to later milestone, since away on sabbatical.

Comment 12

[Stuart Parmenter]

Moving bugs to new Image: GFX component

Comment 13

[Jim Dunn]

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

Comment 14

[Jim Dunn]

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

Comment 15

[Simon Fraser [no longer active]]

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

Comment 16

[Simon Fraser [no longer active]]

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

Comment 17

[Torben]

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

Comment 18

[José Jeria]

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

Comment 19

[Asa Dotzler [:asa]]

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

[Asa Dotzler [:asa]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 22

[Asa Dotzler [:asa]]

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 23

[Simon Fraser [no longer active]]

I did, using NewGWorldFromPtr:
http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Manager/qdref_main/function_group_52.html#//apple_ref/c/func/NewGWorldFromPtr

Comment 24

[Simon Fraser [no longer active]]

Taking back, have patch.

Comment 25

[Simon Fraser [no longer active]]

Attachment: 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

[Simon Fraser [no longer active]]

With this patch the attached image displays fine (as do the Mars rover images).

Comment 27

[Simon Fraser [no longer active]]

This patch also contains a fix for bug 133877 (using ditherCopy)

Comment 28

[Kathleen :Brade]

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 [no longer active]]

Attachment: Added use of cached GDHandle

This patch might be a tad faster.

Comment 30

[Simon Fraser [no longer active]]

Attachment: As above, without the printfs.

Comment 31

[Simon Fraser [no longer active]]

Attachment: Once more

Comment 32

[Conrad Carlen (not reading bugmail)]

Comment on attachment 141390 [details] [diff] [review]
Once more

Patch looks good, works in my testing. r=ccarlen.

Comment 33

[Simon Fraser [no longer active]]

Bryner: any chance of another pageload run with the latest patch?

Comment 34

[Simon Fraser [no longer active]]

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 [no longer active]]

Can I get an sr from someone?

Comment 36

[Asa Dotzler [:asa]]

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 [no longer active]]

I'll land it tonight.

Comment 38

[Simon Fraser [no longer active]]

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

[Josh Aas]

Just built Camino with the patch and it works great. Thanks!

Comment 40

[Benjamin Smedberg]

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

[Simon Fraser [no longer active]]

This was expected, and, in discussions with Asa at Mozilla, was deemed a
worthwhile tradeoff.