Closed Bug 648951 Opened 13 years ago Closed 13 years ago

Fuzzy Zoom to repaint is > 4 seconds on galaxy tab


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



(Not tracked)



(Reporter: dougt, Unassigned)



(Whiteboard: [QA?])


(2 files)

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


1) load
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.
I'm guessing this is bug 598736.
Doug, you say 4 seconds in the bug title and 2 seconds in your STR. Which is it?
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).
Closed: 13 years ago
Resolution: --- → DUPLICATE
Blocks: 598736
Ever confirmed: false
Resolution: DUPLICATE → ---
Done profiling of Fennec zoom by repeatedly double clicking on screen for 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.
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 page is very bad with both nearest and bilinear scaling.
Attachment #525834 - Attachment description: → profiling-fennec-nearest-zoom-on-cnn-com.txt
Ever confirmed: true
OS: Mac OS X → Android
Priority: -- → P2
Hardware: x86 → ARM
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.
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.
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.
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.
(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):
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 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.
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
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
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?
Whiteboard: [QA?]
You need to log in before you can comment on or make changes to this bug.