888794 - [Camera] Image saving to filmstrip takes more time than video

Status: RESOLVED DUPLICATE of bug 866109

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

Description

[Leo]

1. Title : Image saving to filmstrip takes more time than video
2. Precondition : Camera app should be working
3. Tester's Action : 1. Open camera
                     2. Take picture and wait for filmstrip to be shown
                     3. Record video and wait for filmstrip to be shown
 
4. Detailed Symptom (ENG.) : After an Image is captured from camera, it takes more time to show filmstrip. But if you complete recording a video, filmstrip gets updated very fast and filmstrip will be shown very quickly after recording the video.

5. Expected : Time taken to update and show filmstrip should be reduced for Image capture from camera app.

6.Reproducibility: Y
1)Frequency Rate : 100%
7.Gaia Master/v1-train : Reproduced
8.Gaia Revision: 65e861f5941cab66815a2f79b0bc0a6a0fc8f6fe
9.Personal email id: [e-mail]

Comment 1

[(Inactive after June) George Duan [:gduan] [:喬智]]

I think the time difference is because 
when taking picture, app will 1.invoke backend method of take picture (1+ second on inari),2.add picture to storage(almost 1 second) , and then go to filmstrip. 
However, when stop recording video, app will only listen to storage-change event (~300 ms on inari) and go to filmstrip, because step 1 and 2 are already done when start recording video.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Leo from comment #0)

> 
> 5. Expected : Time taken to update and show filmstrip should be reduced for
> Image capture from camera app.
> 

At this point in the cycle we should have explicit performance target metrics to block on.  Is there a certification requirement here?  I'm not sure this is a blocker as it is written without an actionable metric and understanding of what criteria is expected for shipping v1.1.

Comment 3

[Leo]

The requirement is: Saving time for both image and video should be on par.

Comment 4

[Dale Harvey (:daleharvey)]

I dont believe the patch that reverted the 500ms pause after taking photo was applied to v1-train

https://bugzilla.mozilla.org/show_bug.cgi?id=866109

It is likely this is the cause in the use perceived delay, I also agree that 'should be faster' is not what a blocking flag should be for, this file already has numerous conflicts every time a patch needs uplifted, at this point we are just asking to introduce bugs

Comment 5

[Leo]

Dear Dale,

Please let me know if you have any updates for this issue.

Comment 6

[Dale Harvey (:daleharvey)]

The previous patch will need to nommed / agreed blocking and uplifted, posting a comment in there wont help

Marking this as as dupe