Regression: GUI unresponsive during downloads

[GfEW]

First off, I greatly appreciate the efforts put into the huge overhaul that provides so many improvements to v1.0.0!

However after the update, the GUI suddenly feels very laggy at times, even on a reasonably powerful Android 11 phone with Qualcomm 660 octa core and 6 GiB RAM where interaction with other apps feels nice and fluent.

On an Android 9 phone with 2 GiB RAM, NeoStore gets reproducibly unresponsive while packages are being downloaded. It often takes 10 minutes or more to get back to normal.

I've been using NeoStore for years and never experienced any issues with GUI lagginess before, let alone this serious ones.

I don't know all the technical details about the 1.0.0 upgrade, but apparently, some changes have been introduced that adversely affect GUI performance to a degree it's hardly usable on some phones, or very frustrating anyway. None of the GUI improvements I'm aware of are anywhere near making up for such a deterioration of its performance.

I really hope it's just due to an oversight that can easily and quickly be resolved, but otherwise, I see little choice but to revert to 0.9.15.

[ArDrift]

I'm experiencing the same behaviour during an application update's download process, on NeoStore v1.0.0.
I haven't examined the code yet, but my first guess would be that maybe the update process isn't handled on an IO thread but on the UI thread?
So i n this case the UI thread would be fully occupied during downloads/updates, and so it would not obtain enough resources to re-render the UI whenever it's needed (e.g. on any user interaction).

[GfEW]

maybe the update process isn't handled on an IO thread but on the UI thread?

That explanation seems more plausible than my initial "Wild guess: high resolution graphics?" (from OP, edited).
Whilst too-high resolution could explain the choppy scrolling introduced by the upgrade (esp. tiles), that appears to be a separate issue, as it occurs independently of the GUI lockups during updates/downloads.

[opusforlife2]

Implementation of #297 should improve this problem.

[machiav3lli]

@ArDrift @GfEW (also @opusforlife2 ) Not really, it's a recomposition issue. On download, the whole installed/download pages (pre-1.0.1 even all pages) were getting recomposed with each step in of the progress bar, resulting the app to ANR or even crashing (depending on device available resources).

1.0.1 already improve this a bit (excluding the recomposition of the whole UI), but the installed/downloaded pages are still fully unnecessarily recomposed… When working on 1.0.1 I've exhausted all the usual/default methods to debug such recompositions… so when working on next builds (possibly post-1.0.2), I'll be testing some tools: https://github.com/takahirom/decomposer/ , https://github.com/VKCOM/vkompose and/or new Detekt rules…

[opusforlife2]

Are you saying the recomposition is happening due to the download bar showing progress in the UI? If so, maybe it should be removed completely and moved to a download+installation notification?

[machiav3lli]

How does things look on 1.0.2? Specially the ANRs?

[GfEW]

Things seem to be a bit smoother in 1.0.2 in general (not sure) and ANRs less frequent or less persistent, but I still get them when switching tabs, searching, scrolling lists or tiles etc. during ongoing updates or downloads.

On a minor note, even with no updates or downloads going on, those "graphic intense interactions" (that alter large screen areas) are still notably choppy in a way they weren't in 0.9.15.

Maybe there's a bottleneck that is bearable (although notable) without concurrent loads but gets stuck with tighter resources?
If so, could this be related to a fundamental change possibly introduced to the redrawing routines by 1.0.0?

[GfEW]

Brief update:

As of 1.0.5, the GUI still feels much heavier / less fluent than 0.9.x, and continues to frequently get lengthy freezes (up to multiple ANRs), especially during "update all".

That being said, I do notice some improvement. I can't tell by how much each of the post-1.0.0 update contributed to it, but things feel a bit "snappier" now, overall.

EDIT: To see this bug in action, please also check #624. It turns out the screen recording there demonstrates the very behavior described here, and is much more informative than the ignorant non-title suggests (language barrier?).