1024953 - [dolphin][performance]Press the home button to exit the camera takes an average of more than 1.4s, user version takes 1.4s. dolphin and tarako android average time 0.9s

Status: RESOLVED DUPLICATE of bug 1020783

(Firefox OS Graveyard :: Performance, defect)

Description

[yaoyao.wu]

Steps to reproduce the bug:
In the camera screen, press the home button to exit the camera, recording time-consuming, press the home button from the start time to display completely idle stop timing

Comment 1

[James Zhang (Spreadtrum)]

Yaoyao, please attach your analysis and our android dolphin performance data here.
Dolphin android and firefox use the same bsp code base, so I think it's mozilla gaia/gecko performance issue.

Comment 2

[Jan Jongboom [:janjongboom] (inactive)]

Is this camera specific?

Comment 3

[yaoyao.wu]

(In reply to Jan Jongboom [:janjongboom] (Telenor) from comment #2)
> Is this camera specific?

similar problem also appear in gallery:Press the home button to exit the gallery takes an average of more than 1.43s, user version takes 1.28s, 7715GA and android 6821 average time 0.85s

Comment 4

[Jan Jongboom [:janjongboom] (inactive)]

So here's my analysis, I hope you can shine some light on this Alive as the main maintainer of app_window. So basically what happens is:

1. User is in content process, presses HOME
2. [e-mail] is called with callback
3. Callback gets invoked on next paint of homescreen (if not OOM'ed or anything, normal situation)
4. Transition starts

Now this sounds pretty reasonable to me, but between step 2 and step 3 there is a 500 ms. delay (tested on Peak with 2.1) which is crazy. I'm wondering where the trigger for the next paint comes from, as it seems not to be triggered by system app (removing classes on the iframe / parent div does not seem to trigger nextpaint). 

There is *something* going on, because if I set the NEXTPAINT_TIMEOUT to something low (20 ms. or so) the homescreen shows immediately but not all images are painted correctly (filling in), so we do something. The homescreen is not OOMed and is still alive in b2g-ps.

How can we get rid of this 500 ms. delay?

Comment 5

[yaoyao.wu]

(In reply to James Zhang (Spreadtrum) from comment #1)
> Yaoyao, please attach your analysis and our android dolphin performance data
> here.
> Dolphin android and firefox use the same bsp code base, so I think it's
> mozilla gaia/gecko performance issue.


For camera application, which involves mutual cooperation between b2g, camera, mediaserver three processes. ipc itself would be more time consuming, and multi-thread is using runnable mechanisms to cooperate, such benefits are safe, the downside is sacrificing performance. According to the characteristics of  js and java languages, js operating efficiency will be lower than the java (running js, I need at least lexical analysis, parsing, generating bytecode back then parse bytecode js engine running, and has completed the java compiler lexical analysis, syntax analysis, the process of generating bytecode, run-time only need to parse bytecode), finally camera operation will naturally slow.

Comment 6

[Jan Jongboom [:janjongboom] (inactive)]

Tested this on ZTE Open C running 1.4 and here it goes to homescreen instantly.

(In reply to yaoyao.wu from comment #5)
> For camera application, which involves mutual cooperation between b2g,
> camera, mediaserver three processes. ipc itself would be more time
> consuming, and multi-thread is using runnable mechanisms to cooperate, such
> benefits are safe, the downside is sacrificing performance. According to the
> characteristics of  js and java languages, js operating efficiency will be
> lower than the java (running js, I need at least lexical analysis, parsing,
> generating bytecode back then parse bytecode js engine running, and has
> completed the java compiler lexical analysis, syntax analysis, the process
> of generating bytecode, run-time only need to parse bytecode), finally
> camera operation will naturally slow.
Yes, but we don't do anything with the camera when pressing the Home button.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jan Jongboom [:janjongboom] (Telenor) from comment #4)
> So here's my analysis, I hope you can shine some light on this Alive as the
> main maintainer of app_window. So basically what happens is:
> 
> 1. User is in content process, presses HOME
> 2. [e-mail] is called with callback
> 3. Callback gets invoked on next paint of homescreen (if not OOM'ed or
> anything, normal situation)
> 4. Transition starts
> 
> Now this sounds pretty reasonable to me, but between step 2 and step 3 there
> is a 500 ms. delay (tested on Peak with 2.1) which is crazy. I'm wondering
> where the trigger for the next paint comes from, as it seems not to be
> triggered by system app (removing classes on the iframe / parent div does
> not seem to trigger nextpaint). 
> 
> There is *something* going on, because if I set the NEXTPAINT_TIMEOUT to
> something low (20 ms. or so) the homescreen shows immediately but not all
> images are painted correctly (filling in), so we do something. The
> homescreen is not OOMed and is still alive in b2g-ps.
> 
> How can we get rid of this 500 ms. delay?

What we do here is a hack: to use getScreenshot on mozbrowser to force the homescreen to repaint.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/app_window.js#L969

If we want to ignore the repaint and this will become UX issue: the homescreen will be empty/abnormal if we transfer to homescreen right away without waiting it painted.