1142294 - Large images in page are not displayed on low memory devices

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Nicolae Albu]

Attachment: testLargeImageFirefoxAndroid.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

This happens on a low memory device (512 MB RAM).

Open a page with a large image (>= 10000x7000 pixels) with empty alt tag.

I encountered the problem when saving images from different image hosts.
I attached a sample HTML page to isolate it.


Actual results:

Although the image URL is fine, the image is not shown and there is no indication that there might be an image there (to be able at least to save it and open it in another program).

In the sample file, I added text before and after the image.


Expected results:

a) The image should have been shown. Chromium and Webkit based browsers display the large image on the same devices.
b) There should have been an indication of an image, preferably indicating that the image is too large.

If the alt tag is missing, the "broken" file icon is displayed. This usually (95% of time?) means that the image is not accessible. But in this issue's case, it is; at least you should be able to see that so you can save it to disk.

If the alt tag is empty, nothing is shown, although the image is accessible.
There might be (rare) cases when an empty alt makes sense, but not in all current (a lot of) sites on the web. For example, in a image hosting site, the viewed image is 100% working (otherwise it's replaced on server side with a image deleted icon).

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

This bug report has at least two separate issues that it calls out which is not great.

I am able to load the image on a Android One phone with 1 GB of RAM. On a Huawei with 512 MB the image does not load. The test case page does not have an alt tag. On the 512 MB phone Chrome's rendering is downsampled a lot. The image is blurry. Which is bug 945161 though targeted at FxOS but the feature could be cross platform.

The second alt image issue I don't know what our expected behavior here is.

Comment 2

[Nicolae Albu]

Are the two issues the two cases - with an (empty) alt tag and without?
I will split the issue if so.

bug 945161 looks like the best fix for this problem. I will add a comment there.

Comment 3

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

What exactly does "tracking-fennec" mean as far as targeted versions? Do not expect any fix for this to be upliftable.

Comment 4

[Aaron Train [:aaronmt]]

(In reply to Seth Fowler [:seth] from comment #3)
> What exactly does "tracking-fennec" mean as far as targeted versions? Do not
> expect any fix for this to be upliftable.

+ means no target but we're interested in seeing it fixed at some point

Comment 5

[Nicolae Albu]

Shouldn't 1045929 and 1124084 have fixed this (since it's a JPEG image)?
I tested with yesterday's nightly and the image is still not displayed. Do I need to change something in about:config?

Comment 6

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

(In reply to Nicolae Albu from comment #5)
> Shouldn't 1045929 and 1124084 have fixed this (since it's a JPEG image)?
> I tested with yesterday's nightly and the image is still not displayed. Do I
> need to change something in about:config?

I actually haven't filed a bug about this issue yet, and I need to, but I'm not surprised it didn't work on Android. There's a difference in the way that we implement async pan/zoom on Android vs Firefox OS that results in decode-on-draw-only being automatically disabled on Android. Because of that, we try to decode the image at its full resolution. Allocating a texture of that size fails, and the image gets marked as "bad" before downscale-during-decode has a chance to start working.

It's not that hard to fix, I just haven't gotten around to it yet. Thanks for reminding me to move forward on it.

Comment 7

[Nicolae Albu]

Attachment: Workaround

This is a dealbreaker (at least for me).

As a workaround, I created an addon that adds alt text and makes it visible in more cases (empty alt, space alt, alt wth color same as background - who designs this thinks on the web ?!). It's not much, but at least you can see the image placeholder, save it to disk, then open it in another app.
It's attached here (if anyone else bumps into this problem), and it works on desktop version too.

Comment 8

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

(In reply to Nicolae Albu from comment #7)
> This is a dealbreaker (at least for me).

I'm sorry fixing it is taking so long - downscale-during-decode was enabled briefly on Nightly, but it had to be disabled again because of some issues that were discovered. I'm continuing to work on fixing those issues, and I'm hoping to flip it back on again fairly soon.

Comment 9

[Nicolae Albu]

The image doesn't succesfuly load even on 3 GB RAM.
Samsung Galaxy Tab S 10.5, Android 5.0.2, debloated (so more free RAM than by default)

1. Copy the link to the HTML page I attached.
2. Open Firefox and paste & go the URL.
3. The image is shown.
4. Reload the page (sometimes it works the second time, sometimes you need to refresh multiple times).
5. After 1..* reloads, the image is not loaded anymore (like on low memory devices, but this one has 3 GB).

This is reproducible with other images as well.
For the images to load again, I have to force stop Firefox.

Comment 10

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

That image requires 278MB of memory to display. It's being loaded with the HTTP header "Cache-Control: max-age=0", which as currently implemented in Firefox causes us to treat the image cache entry as stale and decode a new copy of the image. The old copy will stick around for a while, until the cache decides to evict it, so memory usage grows by ~278MB every time you reload the page.

That's actually all expected! What is unexpected is that this additional memory usage seems to be causing us to eventually fail to allocate a texture for the image. What should be happening is that when you get to the point where you don't have enough memory to allocate the next texture, we should discard old, unused textures until we have enough memory. So what you're doing should never cause an allocation failure.

That's actually a totally separate bug from this one. I'll file it.

Comment 11

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

I filed bug 1167357.

Comment 12

[Nicolae Albu]

After noticing this in the release notes of 40 beta - "JPEG images use less memory when scaled and can be painted faster", I tried the attached test case:
- Loading was jerkier
- Zooming and panning completely froze my phone (not only Firefox) that I had to force restart it. On a second try, it displayed white with a black rectangle and froze the phone for like a minute (until I closed Firefox from the task manager).

This happened not on the original low memory phone, but on a Samsung S4 mini (1.7 GHz dual Krait 300, 1.5 GB RAM). On 39 stable, everything was fine, but 40 is unusable in this state.

Comment 13

[Nicolae Albu]

Disabling downscale-during-decode (setting image.downscale-during-decode.enabled to false) fixes it.

I also tested on a Tab S (with 3 GB RAM) and same problems, except that it doesn't completely freeze the device.

Comment 14

[Nicolae Albu]

Firefox 40 stable, same problem as in comment 12...

Comment 15

[Nicolae Albu]

Attachment: Image test.zip

Since the original image is not accessible anymore, AND downscale-during-decode has been implemented and enabled, I will update with a new test case (Image test.zip).

The image is a simple orange background of 10000x8000 resolution.
So it would need 10000 (height) * 8000 (width) * 3 (24 bits per pixel) ~= 228 MB memory.

There are 2 cases:
- One where the image is the original size
- One where the image is downscaled to 1024x819 through CSS, so it would need only 2.4 MB of memory

I tested on 3 devices:

- Samsung Tab S, Android 5.0.2, 3 GB RAM
-- Regardless if the image is downscaled or not, or if downscale-during-decode is enabled, or disabled: It might show one time (not every time), but if I refresh, it doesn't show at all until I restart Firefox. This baffled me as the device has plenty of RAM.

- Samsung A3 dual-sim, Android 5.0.2, 1 GB RAM
-- Regardless if the image is downscaled or not, or if downscale-during-decode is enabled, or disabled: The image never loads.

- Samsung S4 mini, Android 4.4.4, 1.5 GB RAM
-- The image loads most of the time. Sometimes, it doesn't, but after a refresh, it does.
-- I also tried significantly larger images, but downscaled to small dimensions, to test downscale-during-decode, but none loaded.

So it looks like failing to load the images on Firefox is not only a limitation of memory.
On any other browser, the images load, regardless of the size (I tried 20000x200000, even unscaled) and much faster, so it's not a fundamental, global limitation.

I don't understand how downscale-during-decode helps.
In all my tests, *none* of the images that failed to load with it disabled were loaded with it enabled.
In my understanding, it *should* help with the cases presented above, like lowering the memory required for an image if it's downscaled (200 MB -> 2 MB), but it doesn't.
Also, other browsers display very large images (bitmap would exceed the available RAM) even in their original size, with huge scrolling, with no lag. How is this possible?

Is there something I'm missing about downscale-during-decode?

Comment 16

[Nicolae Albu]

(In reply to Nicolae Albu from comment #15)
> Created attachment 8714070 [details]
> Image test.zip
> 
> Since the original image is not accessible anymore, AND
> downscale-during-decode has been implemented and enabled, I will update with
> a new test case (Image test.zip).
> 
> The image is a simple orange background of 10000x8000 resolution.
> So it would need 10000 (height) * 8000 (width) * 3 (24 bits per pixel) ~=
> 228 MB memory.
> 
> There are 2 cases:
> - One where the image is the original size
> - One where the image is downscaled to 1024x819 through CSS, so it would
> need only 2.4 MB of memory
> 
> I tested on 3 devices:
> 
> - Samsung Tab S, Android 5.0.2, 3 GB RAM
> -- Regardless if the image is downscaled or not, or if
> downscale-during-decode is enabled, or disabled: It might show one time (not
> every time), but if I refresh, it doesn't show at all until I restart
> Firefox. This baffled me as the device has plenty of RAM.
> 
> - Samsung A3 dual-sim, Android 5.0.2, 1 GB RAM
> -- Regardless if the image is downscaled or not, or if
> downscale-during-decode is enabled, or disabled: The image never loads.
> 
> - Samsung S4 mini, Android 4.4.4, 1.5 GB RAM
> -- The image loads most of the time. Sometimes, it doesn't, but after a
> refresh, it does.
> -- I also tried significantly larger images, but downscaled to small
> dimensions, to test downscale-during-decode, but none loaded.
> 
> So it looks like failing to load the images on Firefox is not only a
> limitation of memory.
> On any other browser, the images load, regardless of the size (I tried
> 20000x200000, even unscaled) and much faster, so it's not a fundamental,
> global limitation.
> 
> I don't understand how downscale-during-decode helps.
> In all my tests, *none* of the images that failed to load with it disabled
> were loaded with it enabled.
> In my understanding, it *should* help with the cases presented above, like
> lowering the memory required for an image if it's downscaled (200 MB -> 2
> MB), but it doesn't.
> Also, other browsers display very large images (bitmap would exceed the
> available RAM) even in their original size, with huge scrolling, with no
> lag. How is this possible?
> 
> Is there something I'm missing about downscale-during-decode?

Anyone?
Why doesn't downscale during decode help for the problem above?

Thanks.

Comment 17

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.