Closed Bug 871821 Opened 8 years ago Closed 8 years ago

Launch latency of Camera application needs to be improved

Categories

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

defect

Tracking

(blocking-b2g:koi+, b2g18+)

RESOLVED DUPLICATE of bug 915083
blocking-b2g koi+
Tracking Status
b2g18 + ---

People

(Reporter: mvikram, Assigned: mikeh)

References

Details

(Keywords: perf, Whiteboard: [c=progress p= s=2013.09.20 u=1.2])

Attachments

(1 file)

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.
Is this slow-down seen only in the camera app?  Or is it affecting all apps?
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)
dale, sotaro: have we changed anything recently that would have slowed down the camera's start-up?
Flags: needinfo?(dale)
Flags: needinfo?(sotaro.ikeda.g)
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?
See Also: → 868997
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
Flags: needinfo?(dale)
blocking-b2g: --- → leo?
tracking-b2g18: --- → ?
See Also: → 872276
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Keywords: perf
Whiteboard: c=
(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.
Flags: needinfo?(sotaro.ikeda.g)
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.
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().
(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.
(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.
Flags: needinfo?(sotaro.ikeda.g)
(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.
(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.
Flags: needinfo?(sotaro.ikeda.g)
So, current implementation have a basic problem of gralloc buffer allocation performance. It is not possible to fix the problem by just small fix.
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
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.
blocking-b2g: leo? → koi?
Depends on: 884595
Priority: -- → P2
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Whiteboard: c= → c= u=1.2 ,
Bug 882552 might affect to Launch latency of Camera application. It is now in m-i.
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.
Assignee: kgrandon → nobody
Status: ASSIGNED → NEW
Blocks: 896833
Assignee: nobody → dhuseby
Status: NEW → ASSIGNED
FxOS Perf will work with Mike Habicher to understand what can be done here.
Assignee: dhuseby → nobody
blocking-b2g: koi? → koi+
Priority: P2 → P1
Whiteboard: c= u=1.2 , → [c= p= s= u=1.2]
Assignee: nobody → mhabicher
Whiteboard: [c= p= s= u=1.2] → [c=progress p= s= u=1.2]
Closing as a duplicate of bug 915083 assigned to Mike Habicher & bug 914916 assigned to Sotaro Ikeda.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Whiteboard: [c=progress p= s= u=1.2] → [c=progress p= s=2013.09.20 u=1.2]
Duplicate of bug: 915083
Hema Koka deleted the linked story in Pivotal Tracker
You need to log in before you can comment on or make changes to this bug.