990292 - [Gallery] can't zoom in on images while the gallery app is scanning other images.

Status: RESOLVED DUPLICATE of bug 1002593

(Firefox OS Graveyard :: Gaia::Gallery, defect)

Description

[Marcia Knous [:marcia]]

Buri, while using:

Gaia   26839cb46f856d610b192f5655a8c38a6bfe0829
SourceStamp d8e8f13bd4ae
BuildID 20140331040200
Version 31.0a1

STR:
1. Open the gallery and select an individual photo
2. Tap on the photo
3. Pinch and zoom to make the photo larger and smaller

Expected: I could pinch and zoom
Actual: pinch and zoom doesn't seem to work

Although on Buri it doesn't seem to work that great on a production device, I am able to tap and at least zoom in a little on the photo.

Nexus 4 seems to pretty smooth when pinching and zooming.

Comment 1

[Hema Koka [:hema]]

Is this is a regression issue?

Comment 2

[Hema Koka [:hema]]

Youngjun, can you find an assignee please

Comment 3

[Youngjun Kim]

It's a gallery application issue. Mozilla gallery engineer can take it.

Comment 4

[Russ Nicoletti [:russn]]

I will investigate.

Comment 5

[Russ Nicoletti [:russn]]

I tried the pinch and zoom functionality on my buri using 1.3 and 1.4. In both cases, the functionality was acceptable as far as I can tell. Also, I didn't see a difference between the 1.3 and 1.4 behavior.

1.3 build:

Gaia      c5cd3a11e91339163b351d50769eaca0067da860
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/5045a67b47ed
BuildID   20140401164001
Version   28.0

1.4 build:

Gaia      26839cb46f856d610b192f5655a8c38a6bfe0829
Gecko     https://hg.mozilla.org/mozilla-central/rev/d8e8f13bd4ae
BuildID   20140331040200
Version   31.0a1

Marcia, can you reflash the 1.4 build again to see if the behavior is consistent for you?

Comment 6

[Marcia Knous [:marcia]]

Russ: I actually reported the bug on Master - I can retest using the build today.

Comment 7

[Marcia Knous [:marcia]]

(In reply to Marcia Knous [:marcia - use needinfo] from comment #6)
> Russ: I actually reported the bug on Master - I can retest using the build today.

Something was going on I think with my cut and paste, but I will definitely check this again.

Comment 8

[Russ Nicoletti [:russn]]

FWIW, I tested using the build in the STR and I'm seeing what seems to be acceptable pinching and zooming on my buri.

Comment 9

[Brogan Zumwalt [Inactive]]

Tested on Buri using latest 1.4 and 1.3, found that pinch to zoom does not seem to function reliably while gallery is still loading images during first time use. If I open an image while gallery is still processing new images pinch to zoom does not work until gallery has finished loading. After this point functionality is restored. I have around 30 images on my sdcard.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140403000210
Gaia: e0186439b9c2c03acd78e9ae011a0071865e7ffb
Gecko: 5bccd264a0e3
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140403004001
Gaia: c5cd3a11e91339163b351d50769eaca0067da860
Gecko: c6c7b01cdb8e
Version: 28.0
Firmware Version: v1.2-device.cfg

Attaching logcat from 1.4

Comment 10

[Brogan Zumwalt [Inactive]]

Attachment: Logcat - First Time Gallery

Comment 11

[Russ Nicoletti [:russn]]

The gallery app, when scanning for new pictures, will prevent zooming (both double-tap zooming and via two-finger pinching) when it has scanned a "big" file -- greater than 2 MB. 

Marcia and Brogan, can you confirm you have at least one picture that is greater than 2 MB on your device?

Assuming that is the case, the reason zooming is prevented when scanning pictures greater than 2 MB is the danger of crashing due to OOM. This constraint will exist until bug 854795 is fixed.

Comment 12

[Russ Nicoletti [:russn]]

Btw, although bug 854795 is resolved, my understanding is there is gaia work remaining to take advantage of the memory-saving gecko feature that was added by 854795. Until the gai work is complete, the zooming constraint will remain. 

I believe these are the two bugs that need to be addressed before the zoom constraint can be removed:

bug 949753, bug 949755

David, can you confirm these are the bugs that affect this zoom constraint?

Comment 13

[Brogan Zumwalt [Inactive]]

I can confirm that I had 1 video appearing in gallery that was over 2 MB in size.

Comment 14

[Russ Nicoletti [:russn]]

I am updating this bug to indicate it is not a [Camera][Madai] bug (based on details in comment #11, comment #12, and comment #13). It is an existing gallery memory usage issue.

Comment 15

[David Flanagan [:djf]]

(In reply to Russ Nicoletti [:russn] from comment #12)
> Btw, although bug 854795 is resolved, my understanding is there is gaia work
> remaining to take advantage of the memory-saving gecko feature that was
> added by 854795. Until the gai work is complete, the zooming constraint will
> remain. 
> 
> I believe these are the two bugs that need to be addressed before the zoom
> constraint can be removed:
> 
> bug 949753, bug 949755
> 
> David, can you confirm these are the bugs that affect this zoom constraint?

Yes, I think that fixing those two bugs should allow us to lift the "big file" restriction. I hope that the restriction is actually based on image size (2 megapixel) and not file size (2 megabyte).  Note that there has been some debate about bug 854795 and I know that someone was working on a different way of acheiving the same basic effect.

I think we'll want to get to these bugs for 1.5.

Comment 16

[Russ Nicoletti [:russn]]

In response to comment #15, yes, the "big file" restriction is based on the image size not the file size.

Comment 17

[David Flanagan [:djf]]

Changing the title and duplicate bug number to more closely match what is actually going on.

Note that all of the "don't zoom while parsing big files" code remains in the gallery app, but now none of it is triggered when working with jpeg images. It will still kick in if we're scanning large PNG or GIF images, and that is probably a good thing because we still need it for those image types.

I've set verifyme in the whiteboard because this is a specific enough bug report that it is worth verifying that it is indeed resolved by bug 1002593.