689707 - Large images download or scale very slowly

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Joe Drew (not getting mail)]

When I'm loading a large image (e.g., the one in the URL bar) on my desktop, the entire image is loaded and displayed almost instantaneously. On my Galaxy Tab 10.1, it takes a very, very long time, despite the fact that both devices are on the same network.

Despite that, it's possible that this is simply a network-is-slow problem; there's no reason to believe that the Tab's 802.11a/n implementation is as good as my notebook's. But I'm worried that we've accidentally started scaling these images bilinearly instead of using nearest-neighbour, making the scale take a very long time. Remember that the Tab has a Tegra 2, which has no NEON.

Comment 1

[Matt Brubeck (:mbrubeck)]

(In reply to Joe Drew (:JOEDREW!) from comment #0)
> I'm worried that we've accidentally started
> scaling these images bilinearly instead of using nearest-neighbour, making
> the scale take a very long time. Remember that the Tab has a Tegra 2, which
> has no NEON.

Yes, we are using bilinear scaling for images on all hardware now.  We decided that the poor quality of nearest-neighbor was hurting us more than the slowness of bilinear, though obviously both have significant downsides.  See bug 669851.

Comment 2

[Joe Drew (not getting mail)]

People might accept the performance ("it's a slow tablet"), but we know better. We need a faster bilinear scale for Tegra.

Comment 4

[Justin Stigall]

Galaxy Tab 10.1 - Android 3.1 (Touchwiz)

While I am sure image quality went up, the slowness in loading an image from almost any Reddit link to imgur.com went from basically instant to unusable.

Images that took a second to load now can take more than 30 seconds to completely load, coming in a few lines at a time.  I can't use firefox mobile on my tablet anymore, even though it's my favorite browser, because every other mobile browser does not have this issue.

Comment 5

[Matt Brubeck (:mbrubeck)]

WebKit on Android 3.0 appears to use nearest-neighbor scaling to quickly render images while scrolling (and possibly other situations) and then redraws them with high-quality scaling.  Joe, how feasible would it be to do something like this in Gecko?

Comment 6

[Florian Hänel [:heeen]]

Experimental scaling of images through separate layers here 650988

Comment 7

[Joe Drew (not getting mail)]

(In reply to Matt Brubeck (:mbrubeck) from comment #5)
> WebKit on Android 3.0 appears to use nearest-neighbor scaling to quickly
> render images while scrolling (and possibly other situations) and then
> redraws them with high-quality scaling.  Joe, how feasible would it be to do
> something like this in Gecko?

I suspect that doing so when a layer is "active" would be the right way to emulate this behaviour. roc/mattwoodrow, do you have any more information to pass on with regard to that?

Comment 8

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

Checking for active layers won't help you here because viewport scrolling is always treated as active.

We probably need to introduce something new, like a global fast vs quality knob.

Comment 9

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

I think bug 650988 is the right thing to do when GL is enabled. No speed vs quality tradeoff is required there.

Comment 10

[Siarhei Siamashka]

(In reply to Joe Drew (:JOEDREW!) from comment #2)
> People might accept the performance ("it's a slow tablet"), but we know
> better. We need a faster bilinear scale for Tegra.

To get faster bilinear scaling on Tegra, at least C fast paths need to be added to pixman:
    http://comments.gmane.org/gmane.comp.graphics.pixman/1004
Additionally skipping interpolation for the alpha channel when it is not needed can provide more speedup.

To make bilinear scaling more suitable for MMX/SSE2/ARMv6 instructions, interpolation precision may need to be reduced a bit (in order to avoid unsigned 16-bit * 16-bit -> 32-bit multiplications):
    http://permalink.gmane.org/gmane.comp.graphics.pixman/1040

Comment 12

[Jeff Muizelaar [:jrmuizel]]

Attachment: Scale faster

This takes the bilinear interpolation routine from skia which reduces the precision from 8 bits to 4. This gives a measurable difference on FishIE on x86, so I'm sure it would help on ARM.

Comment 13

[amir.spamable]

Just investigated a bit more. If a big resolution image is being downloaded/shown(very slow 10 secs for 2 percent) and i go back by back button and come back again using forward button it loads(scaled) instantly. It seems the scaling is being applied while downloading which slows the process. So why not download the image first and show the unscaled version while downloading. And apply scaling once download is complete.

Comment 14

[Matt Brubeck (:mbrubeck)]

Clearing tracking-firefox9; this isn't a new regression in Fx9 and we don't need release-drivers to track it.  We can track this within the mobile engineering team with tracking-fennec.

Comment 15

[amir.spamable]

just another addition, just visiting a different tab and coming back to the image tab do the same trick.....

Comment 16

[Siarhei Siamashka]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)
> Created attachment 563874 [details] [diff] [review] [diff] [details] [review]
> Scale faster
> 
> This takes the bilinear interpolation routine from skia which reduces the
> precision from 8 bits to 4.

Nice, have you considered contributing this optimization to upstream pixman? There are no objections to reducing bilinear interpolation precision in principle:
    http://permalink.gmane.org/gmane.comp.graphics.pixman/1170
Somebody just needs to submit a clean patch.

> This gives a measurable difference on FishIE on x86, so I'm sure it would help on ARM.

For faster FishIE on x86, it may be a good idea use this SSE2 fast path (and add more if needed):
    http://cgit.freedesktop.org/pixman/commit/?id=4dcf1b0107334857e1f0bb203c34efed1146535c

Comment 17

[Siarhei Siamashka]

(In reply to Siarhei Siamashka from comment #16)
> For faster FishIE on x86, it may be a good idea use this SSE2 fast path (and
> add more if needed):
>    
> http://cgit.freedesktop.org/pixman/commit/
> ?id=4dcf1b0107334857e1f0bb203c34efed1146535c

At least this is finally going to be solved by bug 746695. And there are no good reasons other than negligence to still have (bilinear) slow paths in pixman on important use cases ;) Just as hinted earlier in https://bugzilla.mozilla.org/show_bug.cgi?id=628324#c11

Comment 18

[Aaron Train [:aaronmt]]

Is this a Native Fennec issue too?

Comment 19

[Jeff Muizelaar [:jrmuizel]]

https://tbpl.mozilla.org/?tree=Try&rev=36298b80ff9f

Comment 20

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use lower quality interpolation on mobile

Comment 21

[Joe Drew (not getting mail)]

Comment on attachment 622806 [details] [diff] [review]
Use lower quality interpolation on mobile

Review of attachment 622806 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/reftests/image-element/pattern-html-02.html
@@ +5,1 @@
>       Test painting patterns with scaling by background-size and

Why did you have to change this test? Does it work on all platforms?

Comment 22

[Jeff Muizelaar [:jrmuizel]]

(In reply to Joe Drew (:JOEDREW!) from comment #21)
> Comment on attachment 622806 [details] [diff] [review]
> Use lower quality interpolation on mobile
> 
> Review of attachment 622806 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: layout/reftests/image-element/pattern-html-02.html
> @@ +5,1 @@
> >       Test painting patterns with scaling by background-size and
> 
> Why did you have to change this test? Does it work on all platforms?

The test need to change because the top left corner of the image was getting values of 158/159 on platforms with lower interpolation quality causing it to be mapped to white instead of black. This change increases the threshold.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 622806 [details] [diff] [review]
Use lower quality interpolation on mobile

Markus: Are you ok with the test change?

Comment 24

[Markus Stange [:mstange]]

Comment on attachment 622806 [details] [diff] [review]
Use lower quality interpolation on mobile

Sure.

Comment 25

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b9c3d700625a

Comment 26

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/b9c3d700625a

Comment 27

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 622806 [details] [diff] [review]
Use lower quality interpolation on mobile

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: Slower painting on mobile (especially tegras)
Testing completed (on m-c, etc.): Has been on m-c for a while. no problems reported.
Risk to taking this patch (and alternatives if risky): Images could draw wrong, but that's very unlikely. This only changes behaviour on mobile.

Comment 28

[Alex Keybl [:akeybl]]

Comment on attachment 622806 [details] [diff] [review]
Use lower quality interpolation on mobile

[Triage Comment]
Fennec blocker, has had bake time, approved for Aurora 14.

Comment 29

[Catalin Suciu [:csuciu]]

Waiting for the fix to be landed on Aurora

Comment 30

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/63727a5fa570