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.
Phil, could you attach the file please?
I see this behavior in Mac OS X 2001112806
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.
simon? isn't this a quicktime limitation?
*** Bug 124767 has been marked as a duplicate of this bug. ***
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.
It's a QuickDraw limitation that we can't easily work around. The only solution would be to render large images in pieces.
Doh! It's RowBytes, not RowPixels :-)
Assigning to later milestone, since away on sabbatical.
Moving bugs to new Image: GFX component
*** Bug 197646 has been marked as a duplicate of this bug. ***
*** Bug 200376 has been marked as a duplicate of this bug. ***
*** Bug 221698 has been marked as a duplicate of this bug. ***
*** Bug 230952 has been marked as a duplicate of this bug. ***
*** Bug 231704 has been marked as a duplicate of this bug. ***
*** Bug 231745 has been marked as a duplicate of this bug. ***
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
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. ***
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.
Taking back, have patch.
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.
With this patch the attached image displays fine (as do the Mars rover images).
This patch also contains a fix for bug 133877 (using ditherCopy)
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.
Created attachment 141383 [details] [diff] [review] Added use of cached GDHandle This patch might be a tad faster.
Created attachment 141389 [details] [diff] [review] As above, without the printfs.
Created attachment 141390 [details] [diff] [review] Once more
Comment on attachment 141390 [details] [diff] [review] Once more Patch looks good, works in my testing. r=ccarlen.
Bryner: any chance of another pageload run with the latest patch?
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.
Can I get an sr from someone?
Simon, it looks like this has the r and sr needed. Can you land it on the trunk so it can make the Beta?
I'll land it tonight.
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
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?
This was expected, and, in discussions with Asa at Mozilla, was deemed a worthwhile tradeoff.