Bug 695448 (native_droid_panning)

[meta] Panning perf

RESOLVED FIXED

Status

()

Firefox for Android
General
P1
normal
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: elan, Assigned: cwiiis)

Tracking

(Depends on: 1 bug, {meta})

unspecified
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec-)

Details

(Whiteboard: [birch [Product Approved], crash signature)

Comment hidden (empty)
(Reporter)

Updated

6 years ago
OS: Mac OS X → Android
Priority: -- → P1
Hardware: x86 → ARM
(Reporter)

Updated

6 years ago
Assignee: nobody → chrislord.net
(Reporter)

Updated

6 years ago
Whiteboard: [birch]
(Reporter)

Updated

6 years ago
Whiteboard: [birch] → [birch [Product Approved]

Updated

6 years ago
Depends on: 696398

Updated

6 years ago
Alias: native_droid_panning
Blocks: 699303

Updated

6 years ago
Depends on: 699692
(Assignee)

Updated

6 years ago
Depends on: 699351
Copy and pasting my comment from bug 695449, since it's equally relevant here.

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.
Depends on: 700226
No longer blocks: 699303
Depends on: 699303

Updated

6 years ago
Blocks: 699939

Updated

6 years ago
Blocks: 699940
Depends on: 700403
Blocks: 700654
Blocks: 700667
Blocks: 700496
Duplicate of this bug: 700836

Updated

6 years ago
Depends on: 701351

Updated

6 years ago
Depends on: 701381

Updated

6 years ago
Blocks: 694413

Updated

6 years ago
Depends on: 700406

Updated

6 years ago
Depends on: 701406

Updated

6 years ago
Depends on: 700481

Updated

6 years ago
Depends on: 700559

Updated

6 years ago
Depends on: 701408
There is no patch here, but the thing that landed was backed while investigating Talos failures.  Now that tests are green again, we will need to reland.
Depends on: 701586
Depends on: 701623
Depends on: 701627

Updated

6 years ago
Depends on: 701692

Updated

6 years ago
Depends on: 701690
Depends on: 701703
Depends on: 701905

Updated

6 years ago
Crash Signature: :

Updated

6 years ago
Depends on: 701906

Updated

6 years ago
Depends on: 701697

Updated

6 years ago
Depends on: 701701
Depends on: 701911

Updated

6 years ago
Depends on: 702412

Updated

6 years ago
Depends on: 702509

Updated

6 years ago
Depends on: 702907

Updated

6 years ago
Depends on: 702952

Updated

6 years ago
Depends on: 702633

Updated

6 years ago
Depends on: 702676

Updated

6 years ago
Depends on: 702950

Updated

6 years ago
Depends on: 702956

Updated

6 years ago
Depends on: 702983

Updated

6 years ago
Depends on: 703036

Updated

6 years ago
Blocks: 696330

Updated

6 years ago
Blocks: 696379

Updated

6 years ago
Depends on: 703311

Updated

6 years ago
Depends on: 703573

Updated

6 years ago
Depends on: 704978
Depends on: 705169
Depends on: 705170
Depends on: 705171
Depends on: 705217

Updated

6 years ago
Depends on: 703797

Updated

6 years ago
Blocks: 706594
Depends on: 708947
Duplicate of this bug: 708771
tracking-fennec: --- → 11+
Keywords: fennecnative-releaseblocker

Updated

6 years ago
Keywords: fennecnative-releaseblocker → meta
blocking-fennec1.0: --- → ?
blocking-fennec1.0: ? → ---
Summary: Panning perf → [meta] Panning perf
Not tracking on metas.
tracking-fennec: 11+ → -
(Assignee)

Comment 6

4 years ago
I don't believe this meta bug is useful anymore, closing. For what it's worth, panning performance on fennec is really rather good these days and we track this via our talos tests and eideticker.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.