871821 - Launch latency of Camera application needs to be improved

Status: RESOLVED DUPLICATE of bug 915083

(Firefox OS Graveyard :: Gaia::Camera, defect, P1)

Description

[Mandyam Vikram]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31

Steps to reproduce:

We are seeing varying launch latencies (first time launch)for the Camera app over the last few releases. The general trend has been that the launch times have been going higher (please see below). These numbers have been captured on a QRD device.


Actual results:

Here are some results captured over many weeks. 

Build                                      Launch time (ms)                          
QRD B2G AU01.01.00.19.050          1942                                            
QRD B2G AU01.00.01.19.070          2175                                       
QRD B2G AU01.01.00.019.077        2313                                       
QRD B2G AU01.01.00.019.086        2575



Expected results:

We would like to see the launch time improved to < 1500 ms.

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

Is this slow-down seen only in the camera app?  Or is it affecting all apps?

Comment 2

[Mandyam Vikram]

I don't think the slow down is affecting all apps. It is probably related to loading time of the app itself.

I've created different Bugzilla issues for other apps: 
(Contacts: https://bugzilla.mozilla.org/show_bug.cgi?id=871823) 
(Email: https://bugzilla.mozilla.org/show_bug.cgi?id=871826)
(Music: https://bugzilla.mozilla.org/show_bug.cgi?id=871827)

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

dale, sotaro: have we changed anything recently that would have slowed down the camera's start-up?

Comment 4

[Mike Habicher [:mikeh] (high bugzilla latency)]

According to Perf-o-Matic, we're getting cold start times consistent with bug 835367, et al.

https://datazilla.mozilla.org/b2g/?branch=master&range=7&test=cold_load_time&app_list=camera&app=camera&gaia_rev=4e705ae77b41cad5&gecko_rev=a79f866b03fe1dd5

Can you provide us with information on how you measure your first-time-launch times?

Comment 5

[Dale Harvey (:daleharvey)]

I was about to post the same, if I remember the other measurement was calculated to include the first preview being drawn on screen, so if we are seeing slowdown it must be somewhere in the hardware initialisation / getting the preview on screen, the app first drawn hasnt seen any slowdown, I will add an instrument so we can see / track the time taken to 'gotPreviewScreen' in datazilla

Comment 6

[Mandyam Vikram]

Previously, there has been a discussion regarding the methodology being used to get these numbers (please check with Alex or Greg for further details). These are measured using a high speed camera. The discrepancy between the Datazilla numbers and these numbers is that the Datazilla numbers do not account for any activities beyond cold load such as window animation time and any pre load and post load activities including database accesses.

Comment 7

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: logcat for GonkCameraHardware::StartPreview() during camera startup

We are seeing that GonkCameraHardware::StartPreview() is taking varying amount of time during camera launch 632ms to 1100ms. Can any please investigate it. 

Please let us know if we need to pickup any changes from https://bugzilla.mozilla.org/show_bug.cgi?id=835367 to minimize this delay.

Comment 8

[Sotaro Ikeda [:sotaro]]

(In reply to Mike Habicher [:mikeh] from comment #3)
> dale, sotaro: have we changed anything recently that would have slowed down
> the camera's start-up?

I made no change around camera recently.

Comment 9

[Mandyam Vikram]

Based on  Comment 12  in 
https://bugzilla.mozilla.org/show_bug.cgi?id=835367 
should we be expecting 500-600 ms for startPreview()? We are seeing around 820ms or so.

Comment 10

[Sotaro Ikeda [:sotaro]]

There might be a possibility of ImageBridgeChild::AllocSurfaceDescriptorGralloc() became to take longer time, because of other system part's change. It allocate the gralloc buffers used for camera preview. The function is called inGonkNativeWindow::dequeueBuffer().

Comment 11

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Mandyam Vikram from comment #9)
>
> Based on Comment 12 in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=835367 
> should we be expecting 500-600 ms for startPreview()? We are seeing around
> 820ms or so.

What platform are you testing this on? In the past I've observed significantly different timings across platforms, and bug 835367 is specific to Unagi.

Comment 12

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Sotaro Ikeda [:sotaro] from comment #10)
> There might be a possibility of
> ImageBridgeChild::AllocSurfaceDescriptorGralloc() became to take longer
> time, because of other system part's change. It allocate the gralloc buffers
> used for camera preview. The function is called
> inGonkNativeWindow::dequeueBuffer().

You are correct. I found that GonkNativeWindow::dequeueBuffer() is taking almost 247ms for buffer allocation using ImageBridgeChild::AllocSurfaceDescriptorGralloc(). ImageBridgeChild::AllocSurfaceDescriptorGralloc() waits most of the time on http://mxr.mozilla.org/mozilla-b2g18/source/gfx/layers/ipc/ImageBridgeChild.cpp#350 .


We would like to see a solution of this problem. This help to reduce camera launch latency by 200ms to 247ms . 

Could you please explain what do you mean by "other system part's change" ? It may be useful for us to know the changes which led to this problem.

Comment 13

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Mike Habicher [:mikeh] from comment #11)
> (In reply to Mandyam Vikram from comment #9)
> >
> > Based on Comment 12 in 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=835367 
> > should we be expecting 500-600 ms for startPreview()? We are seeing around
> > 820ms or so.
> 
> What platform are you testing this on? In the past I've observed
> significantly different timings across platforms, and bug 835367 is specific
> to Unagi.

We are using QRD 7x27a device.

Comment 14

[Sotaro Ikeda [:sotaro]]

(In reply to Tapas Kumar Kundu from comment #12)
> 
> Could you please explain what do you mean by "other system part's change" ?
> It may be useful for us to know the changes which led to this problem.

Firefox OS was optimized these months(like change task priority). This means that the system can run more tasks when there are the things need to do. Current gralloc buffer allocation method can not provide good performance from architecture point of view. It can be easily blocked by other task.

In content process, the allocation is handled by ImageBridge thread. The thread is also used for camera preview rendering by ImageContainerChild. ImageBridge thread requests b2g process to allocate the buffers via IPDL message. b2g process handle this on compositor thread. And IPDL uses same thread for both transaction(b2g->content, content->b2g). In android, different threads are used for this.

Comment 15

[Sotaro Ikeda [:sotaro]]

So, current implementation have a basic problem of gralloc buffer allocation performance. It is not possible to fix the problem by just small fix.

Comment 16

[Sotaro Ikeda [:sotaro]]

One possible fix is implement IGraphicBufferAlloc instance in b2g process and allocate gralloc buffer via android's Binder ipc. Though it is not a small fix :-(

http://androidxref.com/4.0.4/xref/frameworks/base/include/surfaceflinger/IGraphicBufferAlloc.h#32

Comment 17

[Alex Keybl [:akeybl]]

We'll track for v1.1, we'll set koi? for v1.2 and we'll accept a low risk fix if found for v1.1.

Comment 18

[Sotaro Ikeda [:sotaro]]

Bug 882552 might affect to Launch latency of Camera application. It is now in m-i.

Comment 19

[Kevin Grandon :kgrandon]

Bug 884595 improved gaia performance a bit. It sounds like the remaining issues here are hardware/gonk specific. Unfortunately I don't have the hardware, and am not too familiar with gonk.

While I can keep investigating this one - it doesn't make sense for this to be assigned to me.

Comment 20

[Mike Lee [:mlee]]

FxOS Perf will work with Mike Habicher to understand what can be done here.

Comment 21

[Mike Lee [:mlee]]

Closing as a duplicate of bug 915083 assigned to Mike Habicher & bug 914916 assigned to Sotaro Ikeda.

Comment 22

[Hema Koka [:hema]]

Hema Koka deleted the linked story in Pivotal Tracker