335812 - Scaled large images (either by percent % or by pcx) are displayed only up to a max value

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Image: Painting, defect)

Description

[Andreas Sigg]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060126 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060126 SeaMonkey/1.0

Large images, for example 4400x6560, are displayed with a image scale of 150%, but with a scale of 200% the image is not shown, dependend on how large the browser window is sized.

This is, as far as I am able to evaluate the bug, not a duplicate of the earlier image bugs which were not scaled. Indeed, you can open the image in a browser window, the problem only occurs when you render it inside html code like this:

<img src="http://..." name="pic0" id="PIC" width="100%">

and later do a JavaScript command like this:

document.getElementById( "PIC" ).style.width = "200%";

- then the image disappears instead of being resized.

The problem occurs only at certain maximum values, and only in Gecko browsers but not for example in Konqueror or Internet Explorer.

Reproducible: Always

Steps to Reproduce:
Visit this site for an example:
http://az.ub.uni-freiburg.de/show/fz.cgi?cmd=showpic&ausgabe=01&day=20r&year=1936&month=09&project=3
Choose a percentage of 150% and see how the image vanishes.


Expected Results:  
The image should resize.

Comment 1

[Stephen Deken]

Something about these images is causing gfx to punt on the height calculation.  The calculated height of these images after a resize of arbitrarily large amount is zero or (depending on how this is triggered) another incorrect number.  This seems to be limited to these specific images.

Reporter, how were these images generated?

Comment 2

[Stephen Deken]

I was able to confirm that this is problem is not specific to .png images or even these particular .png images, but related specifically to the dimensions of the images.  It may be related to the amount of available memory; on my Mac the triggering dimensions were much smaller.

Comment 3

[Andrew Schultz]

There are some sanity checks in imglib.  I suspect this hits one of them.  What would be the scaled dimensions when the image stops displaying?

Comment 4

[Stephen Deken]

On my (windows) machine, it fails when the width is set to anything larger than the following width in pixels (value determined by poking around with a javascript shell):

    1454.966613769531363

...which corresponds to a height of approximately 2169 pixels, and doesn't appear to hit any sort of integer boundary.  The failure also occurs when the width is set to auto and the height is set to something larger than 2169.  This is not a memory failure, because setting both the width and the height to an arbitrarily large value result in an image being displayed.

So, we're really looking at a sanity check deep in the bowels of nsHTMLReflowState, I suspect -- somewhere after the image's intrinsic height is queried.  Maybe nsHTMLReflowState.cpp#1378, where we calculate autoHeight as a PRInt32?  That would make us overflow to a negative number at 2,147,483,648, which I'm doubting we hit with this 6,560px tall image.

Maybe in nsImageFrame.cpp#687, where we adjust the image frame to handle the 'auto' value?

I don't have a debug build right now :/