648951 - Fuzzy Zoom to repaint is > 4 seconds on galaxy tab

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Panning/Zooming, defect, P2)

Description

[Doug Turner (:dougt)]

after a zoom, it takes a long time for us to repaint after the fuzzy zoom.

str

1) load cnn.com
2) zoom into any area of the webpage that contains text
3) notice that the font is fuzzy
4) release your pinch/fingers and begin counting
5) notice that it takes over 2 seconds to see the correct clear fonts


I rebooted the device and see the same thing


4.0 didn't looks nearly as bad, although it was somewhat less than instantaneous.

Comment 1

[Benjamin Stover (:stechz)]

I'm guessing this is bug 598736.

Comment 2

[Benjamin Stover (:stechz)]

Doug, you say 4 seconds in the bug title and 2 seconds in your STR. Which is it?

Comment 3

[Matt Brubeck (:mbrubeck)]

With the STR from comment 0, I see about 500ms or less in Firefox 4.0, and around 1000ms in Fennec nightly, on Verizon Galaxy Tab (stock Android 2.2).

Comment 5

[Siarhei Siamashka]

Attachment: profiling-fennec-nearest-zoom-on-cnn-com.txt

Done profiling of Fennec zoom by repeatedly double clicking on screen for cnn.com web page. The performance is quite bad even without bilinear scaling and looks like the bilinear scaling was kind of the last straw which broke camel's back.

Most of the time is spent in plugin-container, and a lot of it is wasted in the kernel (__copy_from_user, __memzero) which might be related to some IO activity and maybe memory allocations which have to be zero initialized. On the pixman side, a lot of time is spent in 'pixman_composite_src_0565_0565_asm_neon' (simple copy) and also 'pixman_composite_src_n_0565_asm_neon' shows up a bit (clear to solid color). These operations are not particularly meaningful by themselves and might indicate some redundant copies of data around.

Nearest scaling is represented by 'pixman_scaled_nearest_scanline_0565_0565_SRC_asm_armv6' and 'pixman_scaled_nearest_scanline_8888_0565_OVER_asm_neon' which together are using quite low percentage of CPU time.

Bilinear scaling looks similar, except that it does not have 'pixman_scaled_bilinear_scanline_8888_0565_OVER_asm_neon' counterpart (scaling with alpha blending). Implementing this missing function with ARM NEON should significantly reduce bilinear scaling contribution on this web page compared to the rest of badness.

Comment 6

[Siarhei Siamashka]

Attachment: profiling-fennec-bilinear-zoom-on-cnn-com.txt

Here is the result of profiling with bilinear scaling enabled.

Percentage of CPU usage by pixman in plugin-container increases from 17.7% to 32.45% compared to nearest scaling. So on average pixman is not even close to be the worst CPU consumer for this page even with bilinear scaling enabled. But I understand that exactly the time of fuzzy to clear text transition is the most interesting.

How precise were the measurements from comment 0? Anyway, later I can try to do some measurements by filming this transition on camera and then counting frames. But subjectively, zooming on this cnn.com page is very bad with both nearest and bilinear scaling.

Comment 7

[Siarhei Siamashka]

I have just installed Android SDK and tried to build Fennec for Android. And immediately found the likely root cause of this issue - bug 656782

This explains why I could not reproduce such a bad performance problem earlier. I was just using Linux for all my tests and benchmarks.

Comment 8

[Siarhei Siamashka]

Doug, could you please re-apply the patches from bug 598736 and check whether the performance is acceptable for you now? I wonder if there is anything that needs to be done here.

Comment 9

[Siarhei Siamashka]

I mean, there is nowhere even close to 4 seconds for repaint after the fuzzy zoom in all my tests (including Galaxy Tab) when NEON optimized bilinear scaling is in use.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

Siarhei - We'd like to find some kind of talos test and see if it measures the affect of the NEON optimizations. Tzoom might do it. I can test it out soon.

Comment 11

[Siarhei Siamashka]

(In reply to comment #10)
> Siarhei - We'd like to find some kind of talos test and see if it measures
> the affect of the NEON optimizations. Tzoom might do it. I can test it out
> soon.

Thanks, any large scale performance tests are very much welcome. The problems/regressions can't be fixed until they are identified. I'm a bit worried that after pixman upgrade, the benchmarks on ARM hardware supposedly identified only one regression, which looked like just a false alarm due to some fault while performing the test (performance regression for that particular use case is just impossible based on how pixman is used there): https://bugzilla.mozilla.org/show_bug.cgi?id=640250#c13

Comment 12

[Matt Brubeck (:mbrubeck)]

In the absence of bug 649041, the only way I know to measure this is stopwatch timing.  These results are on the desktop version of www.cnn.com on an opt trunk build on Verizon Galaxy Tab with stock Android 2.2 (the same device and same test case as comment 3).

Nearest neighbor (without patch from bug 598736):  0.5, 0.4, 0.5 seconds
Bilinear (with patch from bug 5987360):            0.6, 0.6, 0.5 seconds

The precision is highly limited by my reaction time, but we are definitely not seeing the 2-4 second lag reported in the summary and in comment 0, or the >1 second lag reported in comment 3.

Comment 13

[Camelia Urian]

Mozilla/5.0 (Android; Linux armv71; rv:10.0a1) Gecko/20111107 Firefox/10.0a1 Fennec/10.0a1
Device: Galaxy Tab - Android 3.1
        Acer A500 Iconia - Android 3.2

Verified on latest Nightly, with stopwatch on the desktop version of www.cnn.com:
Galaxy Tab: 1.837, 1.233, 1.843, 7.949 seconds
Acer A500 Iconia: 2.139, 1.828, 1.879, 1.900 seconds

Are this times good enough? Can we mark the bug as verified?