695449 - (native_droid_zooming) Zooming perf

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect, P1)

Comment 2

[Patrick Walton (:pcwalton)]

Figured I should comment in this bug. My patch queue is here: http://hg.mozilla.org/users/pwalton_mozilla.com/birch-pan-zoom/

The general design is that we have a Java compositor that renders a large (1024x2048) quad using OpenGL. This is our "display port". It mirrors the e10s separation in XUL Fennec, except that our equivalent of the chrome process is now a Java thread, and the equivalent of the content process is now a Gecko thread. Panning and zooming are in Java and fully asynchronous. The compositor is driven by a "layer client", which is a cached screenshot before Gecko loads and becomes Gecko itself after it's loaded. Thus pan and zoom work before Gecko is up. Gecko renders only in software; there are no GL layers involved on the Gecko side.

This approach mirrors what iOS used to do before version 4 and was chosen due to its combination of simplicity (to get it out the door faster) and good performance. Longer term, the general plan is to use the C++ layer manager decoupled from the rest of Gecko (see Chris Jones' messages to dev.planning for details).

An unresolved question is whether we want panning to be asynchronous or whether we want to sync on Gecko. The benefit of being asynchronous is that panning performance will be higher. The drawbacks are checkerboarding and breaking position:fixed. This approach will work with either choice. Although I'm inclined toward asynchronous panning due to the clear precedent set by other browsers and the excellent performance so far (60 fps for static pages on a range of devices), we should consider both options, because synchronous panning has some advantages and its performance is surprisingly good on fast devices.

Note that I don't believe there are any drawbacks to keeping zooming (this bug) asynchronous, however. Asynchronous zooming is a clear win over synchronous zooming because of the lack of reflows and the use of the GPU for texture scaling. Having position:fixed content "pop in" at the end of a zoom isn't a problem IMHO; most mobile browsers don't bother to redraw during zooming and users are used to that.

The current status is that the physics need work and there are some serious display port/resolution setting/page size issues that prevent this from landing.

Comment 3

[Patrick Walton (:pcwalton)]

Our zoom is quite fast now (60 FPS) and I'm going to close this. We can still use this as a tracking bug; please make zoom bugs block this one.