How to improve MiniClient performance

[stuckless]

I discovered something today, which testing on the Mi Box, using Gemstone. Baically some of my views would get really slow... It would be 1-2 seconds (sometimes longer) when moving from item A to item B, etc. It turns out that the Miniclient was having to purge it's cache in order to show a poster, and the poster sizes were coming in at 1920x2800 (approx), and it was taking up 21mb of memory on the server (and on the Miniclient) to just show it.

The MiniClient (until release 1.2.4 - 2016 dec 22), had a 30mb image cache, so when more than 30mb of images are loaded, then things have to be unloaded in order to make room. At 30mb, the miniclient was spending a considerable amount of time just unloading and unloading images. Keep in mind that EVERYTHING in the miniclient is an image (ie, all fonts, rectangles, boxes, etc).

In Release 1.2.4, I added a setting in the configuration to allow you to change the amount of memory you want to allow for the image cache. For example in my shield, I set mine to 192mb. The default was upped from 30mb to 64mb.

This alone should give some UI smoothness, especially if you were experiencing hiccups in the UI (most likely with fanart enabled).

The other optimisation tip, is related to Gemstone... In the Image Utilities you can set the image scaling options. BACKGROUND and POSTER "FULL" is set to 100 (being 100%). The problem is that many of these background images are REALLY LARGE so using 100% means that each image could be using 20-30mb of memory. This adds up quickly.

I basically set mine to 50. You'll need to clear the memory cache and the disk cache, and because I hate sluggishness... I told Gemstone to prescale everything.

Keep in mind these Android boxes has lots of memory... On the shield, the MiniClient reports having 512mb available for the MiniClient app. So, using 192mb isn't that bad. I haven't checked the Mi Box yet, but it likely has the same or a little less. In the MiniClient settings, if you jump to the bottom, you can see what is being reported as max memory.

[Fuzzy]

I thought those settings were a percentage of UI resolution, but I'll be honest I've never checked that to be the case.

[mackb]

Seems this latest version broke the animation off detection and is blocky. Turning animation back on fixes it. I wouldn't care so much of animations didn't slow the UI down so much.

Thanks,
Mack

[stuckless]

Originally Posted by Fuzzy

I thought those settings were a percentage of UI resolution, but I'll be honest I've never checked that to be the case.

You could be right... but based on the sizes that i'm seeing being sent to the MiniClient for posters... that doesn't appear to be the case... ie, I'm seeing posters that are at least 2x my UI size. Another interesting fact about sagetv... when it loads an image it will load it full size, and the scaling doesn't happen until it reaches the UI, and in the case of the MiniClient it happens ON the miniclient. For example if you have a 1920x2600 but only needs 200x350 on the UI, the UI gets the 1920x2600 image and is told to scale it 200x350. If scaling is happening in the widget, then sagetv is always having to load/process the full size image, and then scale it at the client. I know that Phoenix, using the Image APIs, will handle this per client and create images that scaled and stored, per client, that is exactly the size it needs in the UI, and it avoids the clients having to scale the images, and saves memory on the server, since SageTV is dealing with smaller images.

Originally Posted by mackb

Seems this latest version broke the animation off detection and is blocky. Turning animation back on fixes it. I wouldn't care so much of animations didn't slow the UI down so much.

Thanks,
Mack

I'll push out an update today... I was doing some testing around this, and I left it at the incorrect setting... sorry

[Fuzzy]

Originally Posted by stuckless

You could be right... but based on the sizes that i'm seeing being sent to the MiniClient for posters... that doesn't appear to be the case... ie, I'm seeing posters that are at least 2x my UI size. Another interesting fact about sagetv... when it loads an image it will load it full size, and the scaling doesn't happen until it reaches the UI, and in the case of the MiniClient it happens ON the miniclient. For example if you have a 1920x2600 but only needs 200x350 on the UI, the UI gets the 1920x2600 image and is told to scale it 200x350. If scaling is happening in the widget, then sagetv is always having to load/process the full size image, and then scale it at the client. I know that Phoenix, using the Image APIs, will handle this per client and create images that scaled and stored, per client, that is exactly the size it needs in the UI, and it avoids the clients having to scale the images, and saves memory on the server, since SageTV is dealing with smaller images.

I'm thinknig it is possible the image widget might be able to be tweaked to do the scaling on the server, which would solve most the problems right there (though would still waste server side heap space).

Regarding the gemstone cache, those are using the phoenix image api's for the cached images, so they should be working well (though if it is indeed scaling the percentage based on original image size instead of UI size, that is sort of strange). I honestly have not even looked at gemstone2 to see how he is dealing with images there - it'd be nice to cache them based on the actual used resolutions for the various flows - this might require a few more versions of an image, if it happens to be used at different sizes in different flows, so it would take up more server side space, but it would be the best compromise of quality vs. performance I'd think.

[stuckless]

Originally Posted by mackb

Seems this latest version broke the animation off detection and is blocky. Turning animation back on fixes it. I wouldn't care so much of animations didn't slow the UI down so much.

Thanks,
Mack

FYI... new update posted... out of curiosity what is your device? Just wondering why animations are slow (if it's a phone/tablet, then yeah, i can see it).

[Fuzzy]

Originally Posted by stuckless

FYI... new update posted... out of curiosity what is your device? Just wondering why animations are slow (if it's a phone/tablet, then yeah, i can see it).

I noticed the problem when using my phone remotely. When placeshifting (remote connection), miniclient forces animations to disabled (there is a property [ui/allow_non_local_animations] to override this behavior).

[mackb]

Originally Posted by stuckless

FYI... new update posted... out of curiosity what is your device? Just wondering why animations are slow (if it's a phone/tablet, then yeah, i can see it).

Thanks for the update. It is working great. I am using Mi boxes now but animations have always slowed down UI navigation no matter the device. I can't stand them and even turn them off on my Android phones. They have always seemed like useless fluff to me since I prefer immediate reaction times. I always thought the majority of folks felt the same but I obviously must be wrong.

Cheers,
Mack

[DarkWolf77]

Originally Posted by mackb

Thanks for the update. It is working great. I am using Mi boxes now but animations have always slowed down UI navigation no matter the device. I can't stand them and even turn them off on my Android phones. They have always seemed like useless fluff to me since I prefer immediate reaction times. I always thought the majority of folks felt the same but I obviously must be wrong.

Cheers,
Mack

Interestingly, Android itself actually uses animations like that to mask interface lag. Basically, it's camo to make the interface seem faster when it's actually running slowly. I remember reading up on it way back when Android 4 was released (it's a big part of the "Project butter" they implemented as a methodology to speed up device responsiveness). So a fancy transition is launched while the CPU chugs along in the back to load up the next screen in the background and, hopefully, it's done before or at the same time as the animation finishes.