When clicking URL bar, UI waits on long delay for on capturing thumbnail

[mcomella]

This is a breakout to fix an issue found in the investigations in #8795

STR:

• Open a website and wait for it to load
• Make sure that the bottom bar is visible
• Tap on the URL bar

Expected:
Search screen appears quickly

Actual:
Long pause before search screen appears. Partial cause, from my perf investigation #8795 (comment):

I took a profile on my GS5: https://share.firefox.dev/37SL2of

It appears we're launching a coroutine on a background thread to capture a thumbnail and don't continue on the main thread until it completes. This is backed up by the profile visual where we do onClick, the compositor executes for a while, and we begin main thread execution:

Here's the code where we capture a thumbnail:
https://searchfox.org/mozilla-mobile/rev/f1f9880935a87f0dbdc9d107a9067dbd73338b96/fenix/app/src/main/java/org/mozilla/fenix/browser/BrowserAnimator.kt#123-136

We shouldn't block the UI from appearing on a background operation, especially one that doesn't update information on the subsequent screen.

┆Issue is synchronized with this Jira Task

[mcomella]

It appears this thumbnail is captured to be used for the animation, which prevents the screen from flashing when the animation occurs. In the worst case where we're unable to perform the animation because capturing the thumbnail is too slow, we should check with UX/product but I think a fast flicker is better than a slow, smoother transition.

For non-extreme solutions, maybe we can:

• timeout on the thumbnail capture (not preferred as this still delays the interaction)
• take the thumbnails at different times so they're non-blocking (not sure how to do this efficiently)
• use a different animation that doesn't require a thumbnail (e.g. we seem to be able to do alpha overlays over GV so we could just fade into the new fragment) - I guess this is the ideal one so far

[mcomella]

I ran an experiment where I commented out the thumbnail code and added onComplete where it should be: #8795 (comment) I only measured anecdotally before so I wanted to re-run to ensure this is actually a performance problem and not an inaccuracy with the profiler.

In the original code, on the GS5 over 3 runs, to show the first frame of the SearchFragment, it takes:

• 760ms in the original code
• 261.67ms in the patched version

This confirms fixing this issue will be a big improvement. (Note: this timing does not represent the total duration to show the search screen, just the first frame, but it still good for comparison)

[sblatz]

By changing this as suggested we will lose the cross fade animation we have. This is not possible to mimic without capturing the engine view as we cannot animate the GV layer.

@vesta0 what are your thoughts on losing this animation in favor of a performance win?

Current Cross Fade

Proposed No Cross Fade

[vesta0]

I like the animation but performance takes priority. Thanks @sblatz