Closed Bug 742366 Opened 8 years ago Closed 8 years ago
Jerky performance on double-tap zoom
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.
This may be accentuated on a single-core device too, it would be good to get some testing on lower-end devices.
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.
(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.
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.
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.