Pathetic performance opening in pane *low battery*

[Noitarud]

Describe the bug When device has a low battery <11%, it throttles back performance, and some apps can misbehave. Your app spends much time on each pane refresh (spinning circles work). However search is nigh instant, scroll to next chapter works acceptably (so wish that type of access used more often).

From splash: 3sec for black/white screen 9sec for white with partitions 13sec for circles to appear 22sec for textures (circles begin to not move smooth) 28sec first column text (bible this time) 32sec rest of columns (four panes: two bible, dictionary and strongs. 40s total for three) 8sec for next chapter to appear since one was set near end of Psalm (same regardless of sequence, if ready first or last)

Change chapter: 10s Change workspace: 55s

Bug was found on AndBible version 4.0.651

Smartphone (please complete the following information):

• monocles browser system evaluation

Hardware Brand: Lenovo Manufacturer: LENOVO Model: Lenovo TB-X505F Device: TB-X505F Bootloader: unknown

Software Android: 10 (API 29) Security Patch: 2021-07-05 Build: TB-X505F_S001142_210804_ROW Kernel: 4.9.205-perf+ WebView Provider: com.google.android.webview WebView Version: 94.0.4606.61

Memory Usage App Consumed Memory: 11.67 MiB App Available Memory: 2.12 MiB App Total Memory: 13.78 MiB App Maximum Memory: 192.00 MiB System Consumed Memory: 1,488.69 MiB System Available Memory: 375.34 MiB System Total Memory: 1,864.02 MiB

.

[tuomas2]

Perhaps your OS is disabling graphics acceleration to save battery and thus is killing webview performance.

You can make a screencast video so we can perhaps get more confirmation if that is the case. If that is the case I would say this is wont-fix.

[Noitarud]

Could you make a simple "power saving" interface? (Maybe i can manually disable textures at least) Aren't there faster ways to put text on the screen? My other bible display apps work acceptably still. Video 34mb will have to process it to get under 10mb limit…

[Noitarud]

I tried using ffmpeg to change the resolution, I don't know why it worked so well but its a fraction of a MB now. In retrospect that seems to be faster than most of my figures so maybe it boosted the performance to do the capture, maybe there is a "turbo" switch in android to discover :P.

https://user-images.githubusercontent.com/98794719/233774847-ace18d1e-d4db-479a-9aca-5b75975e1592.mp4

[Noitarud]

Maybe its a webview bug. I read there are different providors, recommend any?

Intro: https://www.quora.com/What-is-Android-Webview-What-are-some-alternatives-to-it https://stackoverflow.com/questions/22459735/is-there-an-alternative-to-webview

[Noitarud]

If you have to leave it as is, query user on verse after chapter is specified, or acknowledge a scroll down to an estimate of there the verse could be.

[tuomas2]

I have not noticed bad performance on my devices even if battery is low. Might be device specific issue. My guess is that your system just puts cpu or gpu to super low performance when battery is low.

If you have to leave it as is, query user on verse after chapter is specified, or acknowledge a scroll down to an estimate of there the verse could be.

What do you mean?

[Noitarud]

This is to get to a verse which is further down, so once it does show I have fewer strokes remaining. •query user on verse (slower by an extra user query - it is as for commentry, asks for book/chapter/verse •acknowledge scroll (preferred, helpful even to users who might be quick to scroll after selecting chapter -few). Use incrementing number in title bar to select verse. Presently, it ignores scrolling until text appears, I, while I wait (rotating ring), try to scroll down to where I think the verse is to save a little time after it appears.

Your app is the worst by far (and in frustration I think to myself "my 486 worked better"), the only other app on whole system that I know is the "JW" app, gives slight continuous issue only if three other conditions are met •right-hand sidebar open •next page not viewed last •present page not last page in publication. So I either close the sidebar or swipe to next page and swipe back. Continuous is perceived with the CPU meter (seen at top in that video) continuous at max and slower page loads/ certain manipulations. And one problem with android networking (EDIT, present opinion, it initialises but does not use USB Ethernet adaptor if plug in when low).

[Noitarud]

Adding to above suggestion (acknowledge scroll) just increment heading "Jer2:1" up.

More traits: I can direct a second window to also look up a scripture, but second will only begin when first is complete, if first is short next chapter gets loaded after second complete. If short it does not take so long.

Is there any way to do four simutaneously since this tablet is advertised as "quad core"? wishful thinking?

[Noitarud]

I found an improvement, maybe the reason it was slow was because your app encumbers it with requests. Technique is to watch the CPU meter (app CPU Stats) at the top, once it goes to zero i switch back to your app.

https://github.com/AndBible/and-bible/assets/98794719/83c5cd90-f37c-4267-ba53-820c5c192fd9

Refresh action was device rotation.

[tuomas2]

Hmm stuff that is being done in UI thread (JS stuff in general) can't be parallelized. Not completely sure what is keeping CPU(s) busy though. It could be JSword side as well, which is run in another worker thread.

[Noitarud]

I think I found the cause thanks to #2888, can you remove all the spinners just in the next beta (or to do so, place in a hidden option or switch, or calc)? You could place a large hourglass emoji perhaps…⏳

[tuomas2]

Spinner is pure css, should not be that heavy. Being pure css it could be disabled with a style package.

[tuomas2]

I can make a test build with disabled spinner (hard-coded) for you to test.

[tuomas2]

Test build will appear here: https://github.com/AndBible/and-bible/releases/tag/build-735_2576_test

[Noitarud]

Here is how it went (good). I had it installed, ran it, then installed 735-norm, and ran that. The app (at end of both examples) was sluggish about filling the bible screen. I didn't really like the android spinners (line/circle) anyway…

https://github.com/AndBible/and-bible/assets/98794719/dc228b7d-3103-4062-b113-58decedc0e7c

[tuomas2]

842 would be good place to implement this, or what do you think?

[Noitarud]

Its all visualisations, so apparently it is. I'll comment about it there…