If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED DUPLICATE of bug 866109

Status

Firefox OS
Gaia::Camera
P1
blocker
RESOLVED DUPLICATE of bug 866109
4 years ago
4 years ago

People

(Reporter: Leo, Unassigned)

Tracking

unspecified
1.1 QE5
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+)

Details

(Reporter)

Description

4 years ago
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: gjyothiprasad@gmail.com
(Reporter)

Updated

4 years ago
blocking-b2g: --- → leo+
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.
(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.
Flags: needinfo?(leo.bugzilla.gaia)
(Reporter)

Comment 3

4 years ago
The requirement is: Saving time for both image and video should be on par.
Flags: needinfo?(leo.bugzilla.gaia)
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
(Reporter)

Updated

4 years ago
Severity: major → blocker
Priority: -- → P1
Target Milestone: --- → 1.1 QE5
(Reporter)

Comment 5

4 years ago
Dear Dale,

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

Updated

4 years ago
Flags: needinfo?(dale)
The previous patch will need to nommed / agreed blocking and uplifted, posting a comment in there wont help

Marking this as as dupe
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(dale)
Resolution: --- → DUPLICATE
Duplicate of bug: 866109
You need to log in before you can comment on or make changes to this bug.