Closed Bug 780336 Opened 9 years ago Closed 9 years ago

BrowserElementScrolling cosumes 7% of profile time on gaia homescreen, but isn't used

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
blocking-basecamp +

People

(Reporter: cjones, Assigned: vingtetun)

References

Details

(Keywords: perf)

Attachments

(1 file)

The homescreen implements its own panning physics, but the BrowserElementScrolling fallback is still kicking in and apparently having its values stomped by the homescreen's.  It's using 7% of profile time which corresponds to a nontrivial framerate difference.

There may be something we can do to make the BrowserElementScrolling code cheaper, or maybe we need to stopPropagation() or something in gaia.  Though it seems that the gaia code runs after BES or the gaia stuff wouldn't "win".
Early-returning from ContentPanning.handleEvent() buys us 3-4fps.
This patch should force an early return in onTouchMove if there is nothing to scroll. (Thanks a lot for the profiling information!)
Assignee: nobody → 21
Status: NEW → ASSIGNED
Attachment #649003 - Flags: review?(jones.chris.g)
Attachment #649003 - Flags: review?(jones.chris.g) → review+
Sent to try:
http://tbpl.mozilla.org/?tree=Try&rev=034dbbabe904
Keywords: perf
OS: Linux → All
Hardware: x86_64 → All
https://hg.mozilla.org/mozilla-central/rev/bd8ac25f41c4
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
blocking-basecamp: --- → ?
You need to log in before you can comment on or make changes to this bug.