search

mvysny / photocloud-frame-slideshow

Android Digital Photo Frame
https://www.android-photo-frame.eu
14 stars 1 forks source link

Tips to reduce cpu usage #146

Open mzakharo opened 3 years ago

mzakharo commented 3 years ago

Hello,

The app uses a lot of CPU the entire time slideshow is on on my Nexus 9. This causes the battery to drain faster than my charger can keep up and causing the slideshow to stop eventually once the device runs out of juice. Fetching photos from the cloud and showing them on screen is not rocket science, yet we burn more cycles than trying to send astronauts to the moon. Are there any settings that can help reduce CPU usage? P.S. htop screenshot with slideshow running: cpu_usage

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/95442357-tips-to-reduce-cpu-usage?utm_campaign=plugin&utm_content=tracker%2F53303527&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F53303527&utm_medium=issues&utm_source=github).
mvysny commented 3 years ago

Fetching photos from the cloud and showing them on screen is not rocket science, yet we burn more cycles than trying to send astronauts to the moon.

Yeah, that's what I thought as well when I embarked on this project...

There are CPU-intensive things going on in the background - every picture fetching not only requires the image decoding and resizing, but also encoding into jpg and storing it into a cache, reading metadata from the image etc.

However, such a high CPU burn is definitely a bad thing. Try to check whether the same CPU usage can be observed when the slideshow shows local photos (photos stored in the phone itself). Also try setting the Photo Show Effect to Static, set Photo Transition Effect to crossfade, try Load with Half Resolution, please try playing with the settings until we can discover the setting which uses lots of CPU.

mzakharo commented 3 years ago

Ken burns seems to have been the biggest problem, causing non-stop CPU usage as per screenshot above. With static image, CPU spikes every time a transition of image occurs, but then settles to 0, so I increased the transition delay between images, monitoring average battery current (power_supply/battery/current_avg ) values are positive again.

mvysny commented 3 years ago

Gotcha, let me take a look. The Ken Burns perhaps... well, burns :-D CPU by animating&rescaling the image too often. It should use at most 60 FPS (or 90/120 FPS if such screen is installed?) but perhaps a cap of 30 FPS could be enough. I'll investigate.

mzakharo commented 3 years ago

Ok, photo delay and static is not the full story. Looks like the issue is when my Google Photo's API account reaches rate limit for the day, then photo-frame begins to poll to retry (roughly every few seconds) -> and this drains the battery and the tablet eventually shuts down. Confirmed, when using internal storage, and large transition delay, the slideshow stays up for days. But with google photos API, as soon as we reach the API limit, large battery drain begins to occur, as confirmed by htop, and photoslideshow process waking up every few seconds to check (in futility) that the stream is rate limited. I believe it does not matter if you check the API every second or every minute, the API counter resets at midnight, and no checks should be done until then. Also, maybe another way to solve this is for the stream retry interval to follow the 'transition delay' setting set by the user. aka -> if user wants to transition every 10 minutes, do not poll any faster than that.

mvysny commented 3 years ago

Yup, the com.flaviofaria:kenburnsview:1.0.7 doesn't support configurable FPS; opened a bug report at https://github.com/flavioarfaria/KenBurnsView/issues/62

the issue is when my Google Photo's API account reaches rate limit for the day

Actually that's PhotoCloud's limit, please see #134 for more details. Hopefully this could be resolved by Google leveraging the API limitation.

Also, maybe another way to solve this is for the stream retry interval to follow the 'transition delay' setting set by the user. aka -> if user wants to transition every 10 minutes, do not poll any faster than that.

It's just the directory listing that's polled quickly; the photos themselves should be then downloaded as fast as they're presented on the screen.