812208 - [camera] Appears a lot of vertical lines on the screen after you take a photo.

Status: RESOLVED DUPLICATE of bug 799801

(Firefox OS Graveyard :: General, defect)

Description

[diana.garcia]

Attachment: camera_vertical lines.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121024073032

Steps to reproduce:

- Go to camera app. 
- Take a photo.
- Check that screen appears properly.




Actual results:

The device show several lines after the user take a photo.



Expected results:

The device should show the photo properly for a few seconds after taking a photo.

Comment 1

[Josh Carpenter [:jcarpenter]]

David, it sounds like this is caused by a hardware bug that may or may not be fixed for v1. In light of that, I suggest we replace the preview with a brief white flash that appears and then fades out (.25 total duration). We can always add the full preview functionality back in later if we confirm that the hardware bug is fixed. In the meantime this patch will prevent a flurry of redundant & frustrated dogfooding reports.

Comment 2

[Dale Harvey (:daleharvey)]

We have the original photo taken, why not put the still frame over it and start resuming the preview asap? we currently wait for a little bit there.

Even with this I think its going to be a problem until it is fixed, I just seen it take 8 seconds. (its usually faster)

Comment 3

[David Flanagan [:djf]]

I've got code in the gallery metadata parser that will find the embedded preview thumbnail in the jpeg file.  If you want to display a smaller image here and in the filmstrip, we could adapt that code for the camera.

(I want to make some memory management changes to gallery and then bump the camera resolution up again, so for speed, it might be good to just display the screen-size thumbnail rather than the full 2-3 megapixel image)

Comment 4

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

It's a dup of a won't fix : bug 799801, unagi only bug; having stated that does comment 3 give indication that there might be a possible fix?

Comment 5

[Dale Harvey (:daleharvey)]

If we are not fixing this at the platform as its unagi specific then I dont really think we should be working around this in gaia. The only thing a fix does is make the camera slower when resumepreviewstream actually does work, and we are still going to be getting a whole bunch of filed bugs as its going to be impossible have this timed correctly

Comment 6

[Josh Carpenter [:jcarpenter]]

I don't fully follow the technical back and forth above. To restate the UX position, in order of importance:

1. Speed. Enable user to take a photo, then quickly take another.
2. Confirmation. Provide indicator that photo has been taken.
3. Preview. Provide preview of photo taken.

Whatever gets us 1 and 2, I'm fine with. A simple white flash per comment 1 would be fine for v1, and we could revisit previews in v2.

Comment 8

[Josh Carpenter [:jcarpenter]]

cc'ing Patryk and Peter for visual design input, in the event that we forego the Show Preview approach and need to implement an alternate visual cue. Guys, for expediency's sake I suggested a white flash that appears at 100% opacity and then fades to 0% over approx .25 second.

Comment 9

[Dale Harvey (:daleharvey)]

When the camera currently takes a photo, the preview is paused at what photo was taken for half a second and then resumes previewing. This is exactly what we want (or at least, what was specified)

The problem is on the unagi the preview turns into green noise when you take a photo, that bug is marked as a WONTFIX because it is unagi specific, doesnt happen on otoro.

This bug is suggesting a workaround for the green noise in gaia, a workaround will not work, gaia has no way to know how and when the preview is broken, a white flash that lasts .25 seconds means we may still see a green noise preview for another 8 seconds or so. Additionally any workaround we do use will have us moving away from what is a fully working solution on the target device.

If we arent solving this in platform because the bug does not exist on our target device, then we are not working around it in gaia because because it is impossible.

Comment 10

[Josh Carpenter [:jcarpenter]]

(In reply to Dale Harvey (:daleharvey) from comment #9)
> When the camera currently takes a photo, the preview is paused at what photo
> was taken for half a second and then resumes previewing. This is exactly
> what we want (or at least, what was specified)
> 
> The problem is on the unagi the preview turns into green noise when you take
> a photo, that bug is marked as a WONTFIX because it is unagi specific,
> doesnt happen on otoro.
> 
> This bug is suggesting a workaround for the green noise in gaia, a
> workaround will not work, gaia has no way to know how and when the preview
> is broken, a white flash that lasts .25 seconds means we may still see a
> green noise preview for another 8 seconds or so. Additionally any workaround
> we do use will have us moving away from what is a fully working solution on
> the target device.
> 
> If we arent solving this in platform because the bug does not exist on our
> target device, then we are not working around it in gaia because because it
> is impossible.

Make sense. FWIW, white flash was proposed as a replacement to showing the preview, not a compliment. So long as the preview works reliably on our target devices, that approach will not be needed.

What about the timing issue? As per the ranking above, it's important that taking consecutive photos is reliably fast. If showing a preview is impeding that and we're not confident of a v1 fix, I'd much rather lose previews than risk multi-second delays.

Comment 11

[diana.garcia]

The device show several lines after the user take a photo.
device: Unagi
Gaia:  52f649c
Gecko: 6073135

Comment 12

[Dale Harvey (:daleharvey)]

> So long as the preview works reliably on our target devices, that approach will not be needed.

We dont explicitly load / show a preview, the stream is paused when a photo is taken, then restarted, its effectively a preview and how the api works. The lines will show up on the unagi regardless. and UX decided that half a second was a reasonable time to pause the preview as it gives you some extra confirmation of the photo you took.

diana if you are going to reopen this bug you need some justification to explain why the WONTFIX is not sufficient

Comment 13

[Jason Smith [:jsmith]]

(In reply to Dale Harvey (:daleharvey) from comment #9)
> When the camera currently takes a photo, the preview is paused at what photo
> was taken for half a second and then resumes previewing. This is exactly
> what we want (or at least, what was specified)
> 
> The problem is on the unagi the preview turns into green noise when you take
> a photo, that bug is marked as a WONTFIX because it is unagi specific,
> doesnt happen on otoro.

That's an insufficient argument to WONTFIX. We track bugs on a device-specific manner that are still open even today. It might affect bug priority, but if it's happening on a device specifically. I'm reopening and renoming for a re-triage based on your input.

Even if it's unagi-specific, that's still a valid bug. As it stands right now, dogfooders are going to hit by this and this exists in a smoketest, so will get continuously flagged. This needs review by Tony on how to handle this case and probably a deeper discussion about the dogfooding experience situation.

> 
> This bug is suggesting a workaround for the green noise in gaia, a
> workaround will not work, gaia has no way to know how and when the preview
> is broken, a white flash that lasts .25 seconds means we may still see a
> green noise preview for another 8 seconds or so. Additionally any workaround
> we do use will have us moving away from what is a fully working solution on
> the target device.
> 
> If we arent solving this in platform because the bug does not exist on our
> target device, then we are not working around it in gaia because because it
> is impossible.

Then move this bug to the platform if the root cause is in the platform that's unagi-specific. I'll bounce this over to bootogecko --> general.

Comment 14

[Dave Hylands [:dhylands]]

So this is unagi specific and won't affect the shipping device, so we're minusing in triage since we wouldn't stop shipping.

Comment 15

[Tony Chung [:tchung]]

reiterating comment 4, dupe of bug 799801 which was a wontfix.  in this case, i think that dogfooders can live with this bug, and it sounds like the fixed work is larger than it should be.  lets keep our devs focused on other blockers for now. 

that said, i wholeheartedly agree with jason in comment 13 that we should not just - bugs cause its on the unagi and not otoro.   Until we have a production device, the unagi is being consumed by QA and dogfooders so we should review unagi specific bugs carefully with a good assessments before acting on -.   Thanks.