Closed Bug 963963 Opened 6 years ago Closed 6 years ago

~2s delay after hitting the call button

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 990003
1.4 S5 (11apr)

People

(Reporter: dietrich, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [c=effect p= s=2014.04.11 u=])

master + m-c, Nexus 4, built on 1/22.

STR:

1. open dialer
2. dial a number
3. touch the green button to initiate call

long delay before call UI opens.

the UI should open immediately.
Dietrich: Does it feel worse than other devices?

We know that the attention screen takes a long time to open and I've been begging Vivien to open a bug explaining everything he explained me. From what I remember, we don't have a Gecko process ready to kick-in.

One mitigation we can do in the the future is dim the screen as soon as the attention screen is displayed (before the transition) but we need bug 927862 and bug 949877 before. That wouldn't speed up opening that screen but at least give feedback to users a bit earlier.
Flags: needinfo?(dietrich)
Flags: needinfo?(21)
There is a few different thing that are ongoing here.

When we open a new window from the dialer app, there is no preloaded TabChild (the process is already here), so we enter one of our slow path. I have some ideas to make that cheaper in the sense that we can precreate a few things but I need to find some cycles to finish bug 939695 for that.

Then I wonder if instead of displaying a UI as soon as we can we are using the telephony API to instatiate a call. As a result we have to dispatch a message to an other process, to the RIL worker thread, wait for the communication to be ready with the operator, and then dispatch a message back to the main thread of the main process, so it can be dispatched on the main thread of the child process. My understanding of this process may be a bit raw and I may be misunderstanding some steps, but in all cases it seems slow, whatever we do.

It may be easy to create a very fast feedback directly from the dialer app, by adding a kind of dark layer once the user has clicked. But sadly this won't fit when the user initiate a call from an other app (like the contacts app).

The issue for the contacts app is different a bit since it also add a new delay by having to send a message back to the main process, so we can check the activities list in the system app, before dispatching a message to the dialer app. 

For solving both cases the idea was to dim the screen with a black layer as explained by Rik in #c2.
It will be far from solving everything since all the steps I describe above will still be here, but it will save a bit of time because the call screen waits to be initialized before doing a transition.

So I realize that this answer is not really an answer for all cases. But it should be easy to make the experience better for the testcase describe by dietrich, but not for contacts, by doing an immediate feedback directly from the dialer app (like dimming the screen here until the call screen is opened).
Flags: needinfo?(21)
Rik: Entire time before call is in progress is only a slightly slower than Android on Nexus 5 in my subjective testing.

However, the time before something visibly happens is much longer - Android UI animates immediately, while ours does nothing for up to 1s sometimes.
Flags: needinfo?(dietrich)
Priority: -- → P3
Whiteboard: [c=effect p= s= u=]
Lots of work happening in the other bug so closing this one.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 990003
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: [c=effect p= s= u=] → [c=effect p= s=2014.04.11 u=]
Target Milestone: --- → 1.4 S5 (11apr)
You need to log in before you can comment on or make changes to this bug.