Closed
Bug 1201322
Opened 9 years ago
Closed 7 years ago
[Gallery] Double-tap zooming action lags and is not smooth
Categories
(Firefox OS Graveyard :: Gaia::Gallery, defect, P3)
Tracking
(blocking-b2g:-, b2g-v2.2 affected, b2g-master affected)
RESOLVED
WONTFIX
blocking-b2g | - |
People
(Reporter: pcheng, Unassigned)
References
Details
(Whiteboard: [2.5-Daily-Testing], [spark])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
Description:
Issue found while verifying bug 1140619. When double tapping to zoom, the zooming action would pause halfway and finishes zooming a second later.
STR:
0) Take some pictures using the device camera
1) Open Gallery and tap to open an image
2) Double tap to zoom in
Expected: Zooming is smooth and nothing out of ordinary should occur.
Actual: Zooming is not smooth. While zooming it appears to pause for a second and after it finishes zooming the resolution of picture then becomes clear.
(continued STR if step 2 doesn't repro):
3) Tap on back button to return to Gallery main view, and repeat steps 1-2.
Repro frequency: 8/10
Note that currently on Aries we have bug 1181290 exhibiting in Gallery. To avoid seeing that issue, I used Flame to demonstrate this issue:
https://www.youtube.com/watch?v=pehWCm6Y0FM
Also attaching a logcat.
Issue occurs on:
Device: Flame 2.5 (319/512MB)
BuildID: 20150902030203
Gaia: b75979ec8862bd5799a7c42e938d3f67be38d6ae
Gecko: fb720c90eb49590ba55bf52a8a4826ffff9f528b
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5)
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
Device: Aries 2.5
BuildID: 20150902124951
Gaia: e2fab8f6ac345ecde10a1350e699be9ceb6987d6
Gecko: 1b687fcb5213153855c7ac0f8392ce0a4a7e3382
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
Reporter | ||
Comment 1•9 years ago
|
||
This issue appears worse on Flame 2.2. In place of the zooming pause on 2.5, 2.2 shows a shifted image for the duration of the pause, and then resumes zooming.
Device: Flame 2.2 (319MB)
BuildID: 20150902032503
Gaia: 335cd8e79c20f8d8e93a6efc9b97cc0ec17b5a46
Gecko: c03e2bc6a3a4
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.2:
--- → affected
status-b2g-master:
--- → affected
Flags: needinfo?(jmercado)
Whiteboard: [2.5-Daily-Testing], [spark]
Comment 2•9 years ago
|
||
[Blocking Requested - why for this release]:
This issue as an offshoot of bug 1140619 which was a blocker for gallery.
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
Comment 3•9 years ago
|
||
Broken functionality. Blocking 2.5 with P3 priority.
blocking-b2g: 2.5? → 2.5+
Priority: -- → P3
Comment 4•9 years ago
|
||
[Blocking Requested - why for this release]: Please reconsider the blocking flag.
What's happening here when we zoom in is that we switch from the EXIF preview image to the full-size image. The 1 second lag is the time it takes the device to decode the image. There's nothing we can do about that. And the tiny jump in the image means that the EXIF preview and the full-size image are not perfectly matched. When the jump happens, I expect that you should also notice the image become sharper.
Bug 1206206 might reduce the wait before the full-size image is displayed, but I'm not certain if it will.
On the Aries device, the camera does not produce suitable EXIF previews, so we don't use them at all, and you don't see that little jump after the image is decoded at full size.
In order to get rid of that tiny jump, I'd have to decode the full image instead of using the preview, and that would have a noticeable performance impact on the display of images before they were zoomed, and would probably have a noticeable memory usage impact as well. Basically, I'm really not sure there is anything we can do about this.
Rather than making it a blocker, I'd rather resolve it as a WONTFIX.
blocking-b2g: 2.5+ → 2.5?
Comment 5•9 years ago
|
||
Based on comment 4, removing from blocking release. But keeping it open and linking to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1206206 to re-check if that helps when the dependency lands.
blocking-b2g: 2.5? → -
Depends on: 1206206
Comment 6•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•