Closed Bug 591822 Opened 14 years ago Closed 7 years ago

Images taller or wider than 32767 (signed short overflow limit) 96DPI pixels fail to be rendered

Categories

(Core :: Graphics: ImageLib, defect)

5 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla32
Tracking Status
blocking2.0 --- -
firefox52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: netrolller.3d, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: regression, testcase)

Attachments

(2 files)

It appears that something in ImageLib is treating image dimensions as 16-bit signed integers, which breaks rendering of images wider or taller than  32767 pixels.

I don't see the point of treating image dimensions as signed integers, given that no image may ever have a negative height or width. Even then, we should use at least a 32-bit integer.

IIRC this worked fine in Firefox 3.5, possibly 3.0 as well, making it a regression.
Is this a matter of using Win32 optimized surfaces for this stuff?  I wouldn't be suprised if they're limited to 16 signed bits....
I would think that finding a regression range would help with the issue, by the way.

Fwiw, on Mac the image renders fine standalone if I'm zoomed out so it fits in the viewport (which is the default setting), but shows a broken image icon if I zoom in.  So it may be an issue with cairo surfaced too, or something.
One thing to note is that it fails to render iven if it's downscaled to 100x100 pixels via HTML or CSS. On the other hand, the following URL (of a smaller image upscaled to 32768*100) renders fine:
data:text/html,<img src="https://www.mozilla.org/images/subsite_back.gif" height="100" width="32768">

I guess that rules out Win32 optimized surfaces.
Last I checked, we optimize at the intrinsic image size and handle height/width stuff by just drawing with a scale at paint time.
(In reply to comment #2) 
> Fwiw, on Mac the image renders fine standalone if I'm zoomed out so it fits in
> the viewport (which is the default setting), but shows a broken image icon if I
> zoom in.  So it may be an issue with cairo surfaced too, or something.

FWIW with Gecko 1.9.2 based builds (Camino nightly) on OS X 10.6, the image renders fine, standalone and embedded, and standalone + zoomed to 100%.

with a recent Minefield build, rendering fails - missing image icon.
On OS X 10.6 I got the following regression range:

fails
Gecko/20100427 Minefield/3.7a5pre
http://hg.mozilla.org/mozilla-central/rev/29a6a85fab8e

works
Gecko/20100426 Minefield/3.7a5pre
http://hg.mozilla.org/mozilla-central/rev/2968d19b0165

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2968d19b0165&tochange=29a6a85fab8e

Possibly:
f236632a9747	Jeff Muizelaar — Bug 542605. Update cairo to 12d521df8acc483b2daa844d4f05dc2fe2765ba6. r=vlad,jwatt,bas Reland after fixing quartz related clipping bug and a bunch of other ones
OK.  Might be worth filing a separate bug on the Mac regression....
(In reply to comment #7)
> OK.  Might be worth filing a separate bug on the Mac regression....

Filed bug 592102.
I can confirm the same regression range on Windows. Changing to All/All.
OS: Windows 7 → All
Hardware: x86 → All
Hmm. The native surface optimization may really the reason... bug 561678 is in that range.
blocking2.0: --- → ?
I don't like this bug, but we can release without fixing it.
blocking2.0: ? → -
I found this bug in some real world testing I've been doing.  I just wanted to fill you in on what I have seen. For the latest release version of Firefox 3.6.11 an image over the width or height limit displays properly on OSX 10.6.

On Windows however the image is displayed, but the image is clipped after the 32768px limit. In Firefox 4 beta 6 on windows the image just shows the broken image icon.

Further to that, loading the image into a canvas tag produces the identical error to just displaying the image in a img tag.

Hopefully that can help people track down the error better.  Please let me know if I can help track it down further as this bug will affect me on an actual website in the future, so I have a vested interest. Not sure I have the skills required to fix it myself or else I would try.
Sorry, one more bit of info that I should of included before. I have tested on the nighties for windows and OSX 10.6 and they both display the broken image icon.
I've been (Lightly) digging into the source code.  I really have no Idea what I'm doing, but I think I found where the problem is.

On Line 43-46 of gfx/cairo/cairo/src/cairo-image-surface.c is

/* Limit on the width / height of an image surface in pixels.  This is
 * mainly determined by coordinates of things sent to pixman at the
 * moment being in 16.16 format. */
 #define MAX_IMAGE_SIZE 32767

I went back and looked at previous builds and it looks like MAX_IMAGE_SIZE was only added to this file on at Wed Apr 07 10:43:35 2010 -0700	d26d9a47e3e0	GECKO193a4_20100407_RELBRANCH

Before that it didn't exist in that file.

Hopefully that can help someone track down the issue. It will take me a while before I figure out how to navigate all the systems to submit a patch myself.
Thanks for the help Derek!

That line you identified appears to have come from a cairo upgrade in april:
http://hg.mozilla.org/mozilla-central/rev/f236632a9747

Cross-referencing the appropriate line in cairo's repository, we find the following commit:
http://cgit.freedesktop.org/cairo/commit/?id=9e45673e

The commit message is:

> The image surface code doesn't reliably work on images larger than 32767 in
> width or height. This patch makes the image surface constructors fail by 
> returning a surface in the CAIRO_STATUS_INVALID_SIZE state when given
> negative or too large dimensions so that client code gets a prompt and
> correct error rather than flaky rendering on large images.

So it sounds like cairo doesn't work correctly when the images are too big. If the cairo guys think such images aren't smart, I don't think it's a good idea for us to override it, and I don't think we have the resources to audit all of cairo and verify that it works correctly for large images.

So it sounds like a WONTFIX is in order, unless somebody has any bright ideas. We could dynamically downscale at decode-time, but I'm not sure if it'd be worth the goop we'd have to put in the decoders...
I'd be concerned if this is a WONTFIX as my testing with all other significant browsers (Even back to IE6) handle images larger than 32767. I wouldn't want Firefox to be the exception browser. I understand why this has become a significantly more difficult bug to fix now though.
(In reply to comment #17)
> I'd be concerned if this is a WONTFIX as my testing with all other significant
> browsers (Even back to IE6) handle images larger than 32767. I wouldn't want
> Firefox to be the exception browser. I understand why this has become a
> significantly more difficult bug to fix now though.

Yeah after thinking about it again I think it makes more sense to leave this bug open but to make it depend on the appropriate cairo bug.
Bug 702906 is probably related to this bug.
http://upload.wikimedia.org/wikipedia/commons/2/28/LC-39_Observation_gantry_pano.jpg is failing to display on my 144DPI screen using Firefox 9.0.1, even though it is only 21239px wide. It displays correctly on another machine with a 96DPI screen.
(In reply to Gábor Stefanik from comment #21)
> http://upload.wikimedia.org/wikipedia/commons/2/28/LC-
> 39_Observation_gantry_pano.jpg is failing to display on my 144DPI screen
> using Firefox 9.0.1, even though it is only 21239px wide. It displays
> correctly on another machine with a 96DPI screen.

The image above is OK on my system: Firefox 10 beta, Windows 7 64-bit, display 1336x768.
(In reply to RNicoletto from comment #22)
> (In reply to Gábor Stefanik from comment #21)
> > http://upload.wikimedia.org/wikipedia/commons/2/28/LC-
> > 39_Observation_gantry_pano.jpg is failing to display on my 144DPI screen
> > using Firefox 9.0.1, even though it is only 21239px wide. It displays
> > correctly on another machine with a 96DPI screen.
> 
> The image above is OK on my system: Firefox 10 beta, Windows 7 64-bit,
> display 1336x768.

What is your current screen DPI setting?
(In reply to Gábor Stefanik from comment #23)
> (In reply to RNicoletto from comment #22)
> > (In reply to Gábor Stefanik from comment #21)
> > > http://upload.wikimedia.org/wikipedia/commons/2/28/LC-
> > > 39_Observation_gantry_pano.jpg is failing to display on my 144DPI screen
> > > using Firefox 9.0.1, even though it is only 21239px wide. It displays
> > > correctly on another machine with a 96DPI screen.
> > 
> > The image above is OK on my system: Firefox 10 beta, Windows 7 64-bit,
> > display 1336x768.
> 
> What is your current screen DPI setting?

96 DPI (100%)
Well, this part of the bug is known to be dependent on a high DPI setting. It appears that the actual width restriction is not 32767, but (32767*96)/(current DPI).
I came across this one too, developing an app for internal use at my company. I created a test case here:

http://canvas-integer-overflow.heroku.com/

(Incidentally, Google Chrome also seems to have this problem in certain configurations).
The DPI-sensitivity part may be worse than it initially seems.

On a 300DPI screen, the size limit is (32768/300)*96 = 10485 pixels, which means, the maximum physical image size we can show on a 300DPI screen is about 88 cm. We don't yet have 300DPI screens of such sizes on the market yet, but this can easily change in the future. (And the higher the DPI goes, the worse this bug will be.)
Summary: Images taller or wider than 32767 (signed short overflow limit) pixels fails to be rendered → Images taller or wider than 32767 (signed short overflow limit) 96DPI pixels fails to be rendered
Blocks: 766661
Another place this bug pops up in the real world is with the screenshot command in the developer toolbar. See bug 766661 for details.
Blocks: 542605
To put the DPI issue in context: Android phones with full-HD displays are beginning to appear on the market - one such phone has a display resolution of 440DPI. The Nokia 808 PureView, on the other hand, has a 41MP camera (image width = 7728px). It won't take long to see these technologies combined in a single device. At 440PPI, the widest image we can display is 7149px - less than the PureView sensor's image width.
repost after mistakenly reporting it under bug 941823:
While reading webcomics online, I encountered a proper example of this issue with FF being unable to display this oversized image (691x50759): http://www.batoto.net/read/_/182566/dice-the-cube-that-changes-everything_ch8_by_soul-scans
Flags: firefox-backlog?
(firefox-backlog flag was cleared because this isn't in the scope of the firefox desktop team)
This should have a much higher priority for the Android platform.

On a Galaxy Note 4 (AFAIK a supported phone), Firefox fails to render full-resolution photos taken with the phone's own camera. The display is 2560p with a reported DPI of 640, which gives a maximum displayable image size of 4915x4915px. The camera snaps pictures @ 5312x2588px.

Since the Galaxy S6 and S6 Edge have the same camera and DPI, they suffer likewise. (S6 Edge Plus and Note 5 are just barely spared by virtue of their 560DPI screen.)
Correction: 5312x2988px on the camera, not 2588.
Summary: Images taller or wider than 32767 (signed short overflow limit) 96DPI pixels fails to be rendered → Images taller or wider than 32767 (signed short overflow limit) 96DPI pixels fail to be rendered
Blocks: slimerjs
Version: Trunk → 5 Branch
The attached testcase works for me with Firefox 48 and the latest Nightly 51.0a1.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
I can still reproduce the problem if HWA is disabled.
The testcase of URL fields fails to render green rectangle.

https://hg.mozilla.org/mozilla-central/rev/01748a2b1a463f24efd9cd8abad9ccfd76b037b8
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 ID:20160825030226
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to Alice0775 White from comment #40)
> https://hg.mozilla.org/mozilla-central/rev/
> 01748a2b1a463f24efd9cd8abad9ccfd76b037b8
> Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
> ID:20160825030226

This build is two days behind the latest Nightly. The latest build is:
https://hg.mozilla.org/mozilla-central/rev/c724ae8bb7b867b6bc65efa1049c0322457ff4b0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0 ID:20160827030436

I confirmed that 20160825030226 did not work with HWA disabled, but 20160827030436 worked for me. Please retest with the (really) latest Nightly.
Flags: needinfo?(alice0775)
(In reply to Masatoshi Kimura [:emk] from comment #41)
> (In reply to Alice0775 White from comment #40)
> > https://hg.mozilla.org/mozilla-central/rev/
> > 01748a2b1a463f24efd9cd8abad9ccfd76b037b8
> > Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
> > ID:20160825030226
> 
> This build is two days behind the latest Nightly. The latest build is:
> https://hg.mozilla.org/mozilla-central/rev/
> c724ae8bb7b867b6bc65efa1049c0322457ff4b0
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101
> Firefox/51.0 ID:20160827030436
> 
> I confirmed that 20160825030226 did not work with HWA disabled, but
> 20160827030436 worked for me. Please retest with the (really) latest Nightly.

Yes, you are right. Fixed by Bug 1007702.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Flags: needinfo?(alice0775)
Resolution: --- → WORKSFORME
Depends on: skia-windows
Bug 1283961 fixed this for PNG images. Some changes in <https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8288d0c7a15&tochange=62d33e3ba514> fixed this for other images with HWA enabled.
Depends on: 1283961
Depends on: 1298652
Depends on: 1298654
(In reply to Gábor Stefanik from comment #36)
> This should have a much higher priority for the Android platform.
> 
> On a Galaxy Note 4 (AFAIK a supported phone), Firefox fails to render
> full-resolution photos taken with the phone's own camera. The display is
> 2560p with a reported DPI of 640, which gives a maximum displayable image
> size of 4915x4915px. The camera snaps pictures @ 5312x2588px.
> 
> Since the Galaxy S6 and S6 Edge have the same camera and DPI, they suffer
> likewise. (S6 Edge Plus and Note 5 are just barely spared by virtue of their
> 560DPI screen.)

Unfortunately, this bug is not fixed on Android yet :(
I filed bug 1298654 to track the Android issue.
(In reply to Masatoshi Kimura [:emk] from comment #43)
> Some changes in
> <https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=c8288d0c7a15&tochange=62d33e3ba514> fixed this for
> other images with HWA enabled.

It was bug 994081. Changing the resolution because we spotted changesets that fixed the bug.
Depends on: 994081
Resolution: WORKSFORME → FIXED
Reopening until the unit test has landed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8785641 - Flags: review?(seth.bugzilla) → review?(aosmond)
Since Google changed their emojis on Hangout last week, the emojis are not displayed anymore in some Firefox.
The image containing all the emojis has a size of 28x33288 and displays blank in my case, so I guess the issue is linked to this bug.

Apparently the issue does not appear when the hardware acceleration is on, but it is not available on my computer (workstation with multiple VMs).
Blocks: 1342697
Hm, did the HWA disabled case regress again? I'm really afraid my review request to unit test is ignored...
Comment on attachment 8785641 [details]
Bug 591822 - reftest to make sure images taller or wider than 32767 pixels will be rendered

https://reviewboard.mozilla.org/r/74782/#review117094

Trying some other reviewers whoever comes first...
Attachment #8785641 - Flags: review?(tnikkel)
Attachment #8785641 - Flags: review?(jmuizelaar)
Comment on attachment 8785641 [details]
Bug 591822 - reftest to make sure images taller or wider than 32767 pixels will be rendered

https://reviewboard.mozilla.org/r/74782/#review117234

::: image/test/reftest/downscaling/reftest.list:204
(Diff revision 2)
> +== huge-1.html?32768x100.png,32768,100 huge-1.html?100x100.png,32768,100
> +fails-if(OSX) == huge-1.html?100x32768.gif,100,100 huge-1.html?100x100.gif,100,100
> +fails-if(OSX) == huge-1.html?100x32768.gif,100,32768 huge-1.html?100x100.gif,100,32768
> +== huge-1.html?32768x100.gif,100,100 huge-1.html?100x100.gif,100,100
> +== huge-1.html?32768x100.gif,32768,100 huge-1.html?100x100.gif,32768,100
> +fails-if(OSX) == huge-1.html?100x32768.jpg,100,100 huge-1.html?100x100.jpg,100,100

What makes these fail on OSX? Are they just off by a fuzz factor? Might be better to fuzz them then.
Attachment #8785641 - Flags: review?(tnikkel) → review+
Comment on attachment 8785641 [details]
Bug 591822 - reftest to make sure images taller or wider than 32767 pixels will be rendered

https://reviewboard.mozilla.org/r/74782/#review117234

> What makes these fail on OSX? Are they just off by a fuzz factor? Might be better to fuzz them then.

Totally broken, unfortunately. Bug 1298652.
Pushed by VYV03354@nifty.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/9afe051a090c
reftest to make sure images taller or wider than 32767 pixels will be rendered r=tnikkel
No longer blocks: 1342697
https://hg.mozilla.org/mozilla-central/rev/9afe051a090c
Status: REOPENED → RESOLVED
Closed: 8 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Pushed by VYV03354@nifty.ne.jp:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c8e5c019cbc
reftest to make sure images taller or wider than 32767 pixels will be rendered
Sorry, accidentally landed on inbound. But I will not backout because it will become an empty commit and disappear on merging.
Flags: needinfo?(masatosh.kimura)
Flags: needinfo?(masatosh.kimura)
Flags: in-testsuite+
Target Milestone: mozilla54 → mozilla32
Comment on attachment 8785641 [details]
Bug 591822 - reftest to make sure images taller or wider than 32767 pixels will be rendered

https://reviewboard.mozilla.org/r/74782/#review119684
Attachment #8785641 - Flags: review?(jmuizelaar) → review+

BhenChod, I'm not sure I follow your comment. The image sizes you list are much smaller than 32767px wide or tall, and in any case this bug has been fixed for over two years now. So chances are, whatever issue you are seeing is not this bug and you should file it as a separate bug, with steps to reproduce.

Flags: needinfo?(mangazuki.online)

Again, this bug as filed was fixed. Please open a new bug with that information.

Flags: needinfo?(mangazuki.online)

@bz: Apparently BhenChod is a spam bot. It copy and pastes old comments and replace the link with a spammy one.

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