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

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Gábor Stefanik]

Attachment: 32768*100px green image, fails to render either separately or embedded in HTML page

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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....

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Gábor Stefanik]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Last I checked, we optimize at the intrinsic image size and handle height/width stuff by just drawing with a scale at paint time.

Comment 5

[philippe (part-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.

Comment 6

[philippe (part-time)]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK.  Might be worth filing a separate bug on the Mac regression....

Comment 8

[philippe (part-time)]

(In reply to comment #7)
> OK.  Might be worth filing a separate bug on the Mac regression....

Filed bug 592102.

Comment 10

[Gábor Stefanik]

I can confirm the same regression range on Windows. Changing to All/All.

Comment 11

[Gábor Stefanik]

Hmm. The native surface optimization may really the reason... bug 561678 is in that range.

Comment 12

[Joe Drew (not getting mail)]

I don't like this bug, but we can release without fixing it.

Comment 13

[Derek]

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.

Comment 14

[Derek]

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.

Comment 15

[Derek]

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.

Comment 16

[Bobby Holley (:bholley)]

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...

Comment 17

[Derek]

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.

Comment 18

[Bobby Holley (:bholley)]

(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.

Comment 20

[Sid]

Bug 702906 is probably related to this bug.

Comment 21

[Gábor Stefanik]

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.

Comment 22

[RNicoletto]

(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.

Comment 23

[Gábor Stefanik]

(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?

Comment 24

[RNicoletto]

(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%)

Comment 25

[Gábor Stefanik]

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).

Comment 26

[PabloBM]

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).

Comment 27

[Gábor Stefanik]

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.)

Comment 28

[Joe Walker [:jwalker]]

Another place this bug pops up in the real world is with the screenshot command in the developer toolbar. See bug 766661 for details.

Comment 29

[Gábor Stefanik]

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.

Comment 30

[David [:Ceremony]]

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

Comment 34

[Jared Wein [:jaws] (please needinfo? me)]

(firefox-backlog flag was cleared because this isn't in the scope of the firefox desktop team)

Comment 36

[Gábor Stefanik]

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.)

Comment 37

[Gábor Stefanik]

Correction: 5312x2988px on the camera, not 2588.

Comment 39

[Masatoshi Kimura [:emk]]

The attached testcase works for me with Firefox 48 and the latest Nightly 51.0a1.

Comment 40

[Alice0775 White]

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

Comment 41

[Masatoshi Kimura [:emk]]

(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.

Comment 42

[Alice0775 White]

(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.

Comment 43

[Masatoshi Kimura [:emk]]

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.

Comment 44

[Masatoshi Kimura [:emk]]

Attachment: Bug 591822 - reftest to make sure images taller or wider than 32767 pixels will be rendered

Review commit: https://reviewboard.mozilla.org/r/74782/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/74782/

Comment 45

[Masatoshi Kimura [:emk]]

Try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8a1d8f7f88c4

Comment 46

[Masatoshi Kimura [:emk]]

(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.

Comment 47

[Masatoshi Kimura [:emk]]

(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.

Comment 48

[Masatoshi Kimura [:emk]]

Reopening until the unit test has landed.

Comment 50

[jeremy.richert1]

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).

Comment 51

[Masatoshi Kimura [:emk]]

Hm, did the HWA disabled case regress again? I'm really afraid my review request to unit test is ignored...

Comment 52

[Masatoshi Kimura [:emk]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=9661df4cb88d5e5266bedb934afc61be59e303d4

Comment 53

[Masatoshi Kimura [:emk]]

Comment on attachment 8785641 [details]
Bug 591822 - reftest to make sure images taller or wider than 32767 pixels will be rendered

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/74782/diff/1-2/

Comment 54

[Masatoshi Kimura [:emk]]

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...

Comment 55

[Timothy Nikkel (:tnikkel)]

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.

Comment 56

[Masatoshi Kimura [:emk]]

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.

Comment 57

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9afe051a090c
reftest to make sure images taller or wider than 32767 pixels will be rendered r=tnikkel

Comment 58

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9afe051a090c

Comment 59

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c8e5c019cbc
reftest to make sure images taller or wider than 32767 pixels will be rendered

Comment 60

[Masatoshi Kimura [:emk]]

Sorry, accidentally landed on inbound. But I will not backout because it will become an empty commit and disappear on merging.

Comment 61

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6c8e5c019cbc

Comment 62

[Jeff Muizelaar [:jrmuizel]]

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

Comment 64

[Boris Zbarsky [:bzbarsky]]

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.

Comment 66

[Boris Zbarsky [:bzbarsky]]

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

Comment 68

[Masatoshi Kimura [:emk]]

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