552412 - Image height limited to 17895698 pixels

Status: UNCONFIRMED

(Core :: Graphics, defect)

Description

[Juergen Ebert]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6

When resizing an image using width and height attributes, the height seems to be limited to 17895698 pixels.

Reproducible: Always

Steps to Reproduce:
1.Add an image using the <img> tag
2.Set height attribute to more than 17895698 pixels.

Actual Results:  
Height of the image is set to 17895698 pixels. This can also been seen in the image properties dialog. Image is displayed completely white in the browser although in the image properties dialog it is shown correctly.

Expected Results:  
Image height should be as set and image should be displayed correctly.

Will attach test case.

Comment 1

[Juergen Ebert]

Attachment: Testcase. Image is shown in a div. Works without the div as well.

One may change the image height to any larger value, result will stay the same.

Comment 2

[zug_treno]

Maybe related to Firefox bug 468386 (-> bug 215055)?

Comment 3

[Boris Zbarsky [:bzbarsky]]

CSS lengths in Gecko are limited to at most (1<<30)-1 app units, with 1<<30 treated as an infinite value.  App units are 1/60 of a CSS pixel.  Lengths larger than that effectively overflow the integer datatype used to store lengths.

  ((1<<30)-1)/60 == 17895697

which is the maximum CSS length, in CSS px, that we support, effectively.

Looks like a duplicate of bug 265084, pretty much.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Indeed. I'm having trouble caring, though.

Comment 5

[Juergen Ebert]

Seriously? Well, this limitation caused a bug reported against our software. And why not switch to IEEE double? I know that in 2004 you said it would "use a *lot* more memory" but I don't believe this to be true anymore if it ever was.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you explain why someone would want to scale an image to over 17 million pixels high? On a 96dpi screen, that's over four kilometers high.

Comment 7

[Juergen Ebert]

It is used for displaying a search result in a table which has like a million rows. Since it is not possible to actually show all the entries, the image instead is placed in a scrollable div and the scroll position is used as a reference for which part of the results to show.
And on a 300dpi screen it's a little over 1.5km only. ;)

Comment 8

[Boris Zbarsky [:bzbarsky]]

> And why not switch to IEEE double? 

In addition to the memory issue, because they're slower to do arithmetic on and harder to use without getting weird rounding issues.

> but I don't believe this to be true

Don't believe, or have data showing otherwise?  It would approximately double the size of many layout data structures, including most of the ones that account for the bulk of our memory usage last I measured.

In any case, I don't believe any current rendering engine does doubles for coordinates last I checked...  Then again, they may also not do subpixel positioning, which is where that factor of 60 comes in.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We'd use floats, not doubles, so there wouldn't be a memory issue, but there would be speed and code size issues as Boris says.

I believe IE8's "IE8 mode" engine can do some subpixel positioning. I don't know how it behaves on this test.

If you increase the height of the table by 60x then all other engines are going to start hitting 32-bit limits, since AFAIK no engine uses doubles or floats. Basically, the strategy of making arbitrary-height elements falls down sooner or later.