Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Mac can't handle images >4095 pixels

RESOLVED FIXED in mozilla1.5beta

Status

Core Graveyard
Image: Painting
--
major
RESOLVED FIXED
16 years ago
6 years ago

People

(Reporter: Phil, Assigned: Simon Fraser)

Tracking

Trunk
mozilla1.5beta
PowerPC
Mac OS X
Bug Flags:
blocking1.7a -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Phil, could you attach the file please?
(Reporter)

Comment 2

16 years ago
Created attachment 60381 [details]
jpeg used to recreate the problem.. panorama of desert camping.

Comment 3

16 years ago
I see this behavior in Mac OS X 2001112806
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Target Milestone: --- → Future

Comment 4

16 years ago
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.
Severity: normal → major
Summary: wide graphic won't display at all → JPEG images >4095 pixels wide do not display
Target Milestone: Future → ---

Comment 5

16 years ago
simon?  isn't this a quicktime limitation?

Comment 6

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

Updated

16 years ago
Summary: JPEG images >4095 pixels wide do not display → Mac can't handle images >4095 pixels

Comment 7

16 years ago
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.
(Assignee)

Comment 8

16 years ago
Mine
Assignee: pavlov → sfraser
(Assignee)

Comment 9

16 years ago
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

16 years ago
Doh!  It's RowBytes, not RowPixels :-)
(Assignee)

Comment 11

16 years ago
Assigning to later milestone, since away on sabbatical.
Target Milestone: --- → mozilla1.2alpha

Comment 12

16 years ago
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX

Comment 13

15 years ago
*** Bug 197646 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.2alpha → mozilla1.5alpha

Comment 14

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

Updated

15 years ago
(Assignee)

Updated

14 years ago
Target Milestone: mozilla1.5alpha → mozilla1.5beta
(Assignee)

Comment 15

14 years ago
*** Bug 221698 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

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

Comment 17

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

Comment 18

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

Comment 19

14 years ago
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

14 years ago
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
*** Bug 232943 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking1.7a?

Comment 22

14 years ago
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.
Flags: blocking1.7a? → blocking1.7a-
(Assignee)

Comment 23

14 years ago
I did, using NewGWorldFromPtr:
http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Manager/qdref_main/function_group_52.html#//apple_ref/c/func/NewGWorldFromPtr
(Assignee)

Updated

14 years ago
Assignee: sfraser → nobody
(Assignee)

Comment 24

14 years ago
Taking back, have patch.
Assignee: nobody → sfraser
(Assignee)

Comment 25

14 years ago
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.
(Assignee)

Comment 26

14 years ago
With this patch the attached image displays fine (as do the Mars rover images).
Status: NEW → ASSIGNED
(Assignee)

Comment 27

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

Comment 28

14 years ago
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.
(Assignee)

Comment 29

14 years ago
Created attachment 141383 [details] [diff] [review]
Added use of cached GDHandle

This patch might be a tad faster.
(Assignee)

Updated

14 years ago
Attachment #141300 - Attachment is obsolete: true
(Assignee)

Comment 30

14 years ago
Created attachment 141389 [details] [diff] [review]
As above, without the printfs.
Attachment #141383 - Attachment is obsolete: true
(Assignee)

Comment 31

14 years ago
Created attachment 141390 [details] [diff] [review]
Once more
Attachment #141389 - Attachment is obsolete: true
Comment on attachment 141390 [details] [diff] [review]
Once more

Patch looks good, works in my testing. r=ccarlen.
Attachment #141390 - Flags: review+
(Assignee)

Comment 33

14 years ago
Bryner: any chance of another pageload run with the latest patch?
(Assignee)

Comment 34

14 years ago
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.
Attachment #141390 - Flags: superreview?(bryner)
(Assignee)

Comment 35

14 years ago
Can I get an sr from someone?
Attachment #141390 - Flags: superreview?(bryner) → superreview+

Comment 36

14 years ago
Simon, it looks like this has the r and sr needed. Can you land it on the trunk
so it can make the Beta?
(Assignee)

Comment 37

14 years ago
I'll land it tonight.
(Assignee)

Comment 38

14 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 39

14 years ago
Just built Camino with the patch and it works great. Thanks!
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?
(Assignee)

Comment 41

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

Updated

8 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.