Closed Bug 742366 Opened 8 years ago Closed 8 years ago

Jerky performance on double-tap zoom

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox14 --- affected
blocking-fennec1.0 --- beta+

People

(Reporter: aaronmt, Unassigned)

References

Details

Post landing on bug 737577, I am testing an inbound-build today looking at the performance of double-tap zooming. On double-tap zoom inwards I am seeing jerky performance, a somewhat 'two step 'kick' process before finalizing the last paint.

See video (seeing the 'kick' is most noticeable when looking at the images): 

http://www.youtube.com/watch?v=Jt9jqrkdcV0&hd=1

I am seeing this on a few tested sites, such as:

* www.randsinrepose.com
* www.nytimes.com
* www.torontoist.com 

--
Samsung Galaxy Nexus (Android 4.0.4)
20120404063622
http://hg.mozilla.org/integration/mozilla-inbound/rev/13b84bf759eb
Yeah, the jank there is most likely because the texture upload happens while we are zooming and blocks the compositor. Tiling and/or progressive upload will help with this. If those don't help we can back out bug 737577, or maybe find some way to delay the upload until we have finished the zoom. In some ways this is worse than the original bug, I think.
Blocks: the_jay_bug
This may be accentuated on a single-core device too, it would be good to get some testing on lower-end devices.
Keywords: qawanted
Depends on: 739679
blocking-fennec1.0: ? → beta+
Looks like qawanted here.  It's been six days, and we need an update.
I can still reproduce this on Nightly (04/11).
This seems to be equally bad on my g2 (800mhz 512mb ram) vs. the Galaxy Nexus.

I can reproduce this by quad tapping on the same spot. Another slightly less reliable method seems to be triple tapping to put Fennec in the in-between zoom state then double tapping in a different part of the screen.
Keywords: qawanted
(In reply to Damon Sicore (:damons) from comment #3)
> Looks like qawanted here.  It's been six days, and we need an update.

Its dependent on the tiled thebes layer work.
I just reproduced this on my Galaxy S with nytimes.com. It looks like we're animating the zoom to one zoom level and then re-rendering to a slightly different zoom level, which causes a jump.
This needs to be assigned.
I'm having a much harder time seeing this right now.  The original thought was that the the texture upload happened in the middle of the zoom out animation.  With bug 745177, would we mostly avoid this?

Otherwise without async texture uploads this will be hard to avoid, correct?
If this is no longer pronounced, we'll minus.
Keywords: qawanted
Having tested on a latest-inbound (04/17), yes, this is less noticeable than prior yet still present. It's improved but still there.
(In reply to JP Rosevear [:jpr] from comment #9)
> I'm having a much harder time seeing this right now.  The original thought
> was that the the texture upload happened in the middle of the zoom out
> animation.  With bug 745177, would we mostly avoid this?
> 
> Otherwise without async texture uploads this will be hard to avoid, correct?

I could be wrong but I thought the EGLImage stuff pcwalton was working on would kill this. Alternatively we could back out bug 737577 which introduced it.
clearing qawanted per comment 11.
Keywords: qawanted
Let's retest this after bug 739679 and bug 730718 land
Depends on: 730718
lots of stuff has landed which has made this a lot better
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.