1144983 - Huge image (15000x15000) fails to display correctly

Status: RESOLVED DUPLICATE of bug 1146663

(Core :: Graphics, defect)

Description

[Alice0775 White]

+++ This bug was initially created as a clone of Bug #1063581 +++

This does not happen in Firefox36.

Steps To Reproduce:
1. Open attachment 8505758 [details]


Actual results:
image is black

Expected results:
image should appear.

Comment 1

[Alice0775 White]

#1 Regression range, Browser crashes
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=165c3fd176ec&tochange=d954ed24e795

Triggered by: Bug 902952

#2 Regression range, Fixed the crash, But the image is black.
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c61c91ea40fe&tochange=0a69bc9e746c

Triggered by: Bug 1078693

Comment 2

[Alice0775 White]

[Tracking Requested - why for this release]:
Regressed since Firefox37.
Should be fixed next ESR38.

Comment 3

[Liz Henry (:lizzard)]

Tracking this for 37 and 38. 
Bas is this something that you think should be a priority ?

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Liz Henry (:lizzard) from comment #3)
> Tracking this for 37 and 38. 
> Bas is this something that you think should be a priority ?

Yes, I believe so, especially as I don't have an explanation right now. I will investigate.

Comment 5

[Bas Schouten (:bas.schouten)]

So this won't draw without D2D 1.1 either. The problem appears to be that we're simply running out of memory, this image is 15000x15000, at 4bpp this means that it will take 900 MB of memory. For reasons beyond my knowledge we choose to de-optimize this image. When de-optimizing we create a VolatileBuffer the size of the surface, but in order to get our data in there we -also- need to create a D3D software buffer to readback to. This brings us to requiring two blocks of 900 MB of contiguous memory which we simply don't have at our disposal.

I could look a little bit about whether I could improve the code in Deoptimize but I really don't think so as long as we really need to use a volatile buffer. Seth might be able to say more about this.

As for the regression ranges, my suspicion is that while the bug that caused the crash was there, we changed imagelib code to have the new memory requirements, when the crash-bug was fixed we weren't able to draw this anymore.

Comment 6

[Seth Fowler [:seth] [:s2h]]

Sounds like bug 1146663 will fix this, since that will remove the necessity for imgFrame::Deoptimize totally.

Liz, any fix here is not going to be upliftable. Given that this is a corner case (images this large are very rare), IMO would should not track for 37 and 38. Are you OK with removing the tracking flags here?

Comment 7

[Liz Henry (:lizzard)]

Yes, that makes sense to me. Thanks Bas and Seth for investigating and for the explanations! 

This isn't tracked for 37, but would you mind marking it wontfix for 37 and 38?  Would you rather that I leave for you to do, or should I go ahead with the flag-tweaking when you have made your intent clear in comments?

Comment 8

[Seth Fowler [:seth] [:s2h]]

Sure, I'll update the flags.

Comment 9

[Bas Schouten (:bas.schouten)]

I'm not convinced this should even be tracked for 39, fwiw. It's nice to have, but as Seth said, when you have images this large, there's just always going to be a good chance in the current code that we won't have the contiguous memory for them.

Unassigning since Seth's bug is going to take care of this problem in the longer run.

Comment 10

[Liz Henry (:lizzard)]

Thanks for the extra explanation, Bas! Untracking.

Comment 11

[u279076]

Alice, does this still reproduce for you since bug 1146663 was resolved?

Comment 12

[Alice0775 White]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #11)
> Alice, does this still reproduce for you since bug 1146663 was resolved?

Yes, it fixed.
I can reprosuce the pronlem on Firefox42.0b5.
But, I cannot reproduce on Autora43.0a1 and Nightly44.0a1.