742366 - Jerky performance on double-tap zoom

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

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

Comment 1

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 2

[Chris Lord [:cwiiis]]

This may be accentuated on a single-core device too, it would be good to get some testing on lower-end devices.

Comment 3

[Damon Sicore (:damons)]

Looks like qawanted here.  It's been six days, and we need an update.

Comment 4

[Aaron Train [:aaronmt]]

I can still reproduce this on Nightly (04/11).

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 6

[JP Rosevear [:jpr]]

(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.

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

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.

Comment 8

[Erin Lancaster [:elan]]

This needs to be assigned.

Comment 9

[JP Rosevear [:jpr]]

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?

Comment 10

[JP Rosevear [:jpr]]

If this is no longer pronounced, we'll minus.

Comment 11

[Aaron Train [:aaronmt]]

Having tested on a latest-inbound (04/17), yes, this is less noticeable than prior yet still present. It's improved but still there.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(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.

Comment 13

[Tony Chung [:tchung]]

clearing qawanted per comment 11.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Let's retest this after bug 739679 and bug 730718 land

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

lots of stuff has landed which has made this a lot better