Closed Bug 979135 Opened 9 years ago Closed 3 years ago

Use custom layouts for toolbar

Categories

(Firefox for Android Graveyard :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: wesj, Unassigned)

Details

Attachments

(1 file)

It might be nice to move to custom layout/measuring code for BrowserToolbar. RelativeLayouts aren't fast (and ours has one item with weight). Maybe we can do better?
Attached patch WIP PatchSplinter Review
This was a WIP I started here trying to get things to work on my phone (before I moved on to making it work on other phones/tablets). Using this I measured these methods taking around 2-20ms.

However, commenting these out and doing some timing in the normal methods (with calls to super.onMeasure()/etc) I didn't see a huge win. I saw a few 200ms calls, but most were very fast (2-20ms, maybe they're very smart about avoiding work if they can?)

Lucas, you have any idea if this is the right path here? Any advice?
Flags: needinfo?(lucasr.at.mozilla)
(In reply to Wesley Johnston (:wesj) from comment #1)
> Created attachment 8385114 [details] [diff] [review]
> WIP Patch
> 
> This was a WIP I started here trying to get things to work on my phone
> (before I moved on to making it work on other phones/tablets). Using this I
> measured these methods taking around 2-20ms.
> 
> However, commenting these out and doing some timing in the normal methods
> (with calls to super.onMeasure()/etc) I didn't see a huge win. I saw a few
> 200ms calls, but most were very fast (2-20ms, maybe they're very smart about
> avoiding work if they can?)
> 
> Lucas, you have any idea if this is the right path here? Any advice?

Yep, something along these lines. What I had in mind was to implement a measure/layout logic that is a lot more specific to our UI. So, BrowserToolbar would subclass ViewGroup (instead of RelativeLayout) and we'd optimize the measure/layout logic to our use case.

In any case, you're right: we'll have to benchmark the custom layout to evaluate whether it's worth the extra code. My guess is that custom layout implementations will give us bigger perf improvements on containers higher up in the hierarchy (especially if they involve multi-pass layout traversals).
Flags: needinfo?(lucasr.at.mozilla)
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.