Working...
#16
Well technically I'd call this both a bug and a feature request! Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#17
How would one go about replacing the animation with a static image??
If I have been of help, please add to my reputation as a way of saying thanks, it's free.
Reply
#18
Remove the <animation> tag, as it's this that rotates the current image through 360 degrees, and then replace the current "busy.png" with something more suitable as a static image.

Although to be honest I don't see the point of an entirely static image as you may as well have no image at all. Ideally you just want something that still indicates progress, but hammers the GUI far less than the current version.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#19
I'm glad this is actually being addressed. I raised this concern about a year ago, in particular with a skinner of a well known skin. Was told basically that as it wasn't a percentage or a timeline the pi cpu usage was negligible. I've since edited the .xml and noticed a nice decrease in load times.
Reply
#20
(2013-07-19, 22:49)MilhouseVH Wrote: Remove the <animation> tag, as it's this that rotates the current image through 360 degrees, and then replace the current "busy.png" with something more suitable as a static image.

Although to be honest I don't see the point of an entirely static image as you may as well have no image at all. Ideally you just want something that still indicates progress, but hammers the GUI far less than the current version.
MilhouseVH,

While doing as you suggest might fix the problem, the underlying problem is not the busy spinner as such but the fact that the Dirty region code is updating the entire screen for each frame of the animation. If you change the dirty region algorithm type in the adavancedsetting.xml file to use the only update the part of the screen that has changed algorithm (from memory type 2, sorry tried to check the wiki for this but it's down at the moment). So add this line to the as.xml file

PHP Code:
<algorithmdirtyregions>2</algorithmdirtyregions

The default setting for this is to update the entire screen anytime there is any change, so in the case of the spinner, update a small part of the screen or update the whole screen. I'm sure you can guess which would be quicker (and less load on the Pi).

There is maybe another way to reduce the load on your system (that is if you are running a very recent build of Gotham), that is to reduce the maximum frame rate in the as.xml file. The XBMC GUI is rendered in a big game loop, so if you reduce the number of times the Gui loop is executed, your CPU load must go down.

As to replacing the animated image with a static image, how do you tell if your Pi has hung instead of just busy off doing something?

Wyrm (xTV-SAF)
If required a FULL debug log can now be submitted from the skin in settings->skin settings->support. Or follow instructions here if you can't access skin settings.

FAQ's located at :- http://kodi.wiki/view/Add-on:AppTV
Reply
#21
(2013-07-20, 18:27)wyrm Wrote: While doing as you suggest might fix the problem, the underlying problem is not the busy spinner as such but the fact that the Dirty region code is updating the entire screen for each frame of the animation. If you change the dirty region algorithm type in the adavancedsetting.xml file to use the only update the part of the screen that has changed algorithm (from memory type 2, sorry tried to check the wiki for this but it's down at the moment). So add this line to the as.xml file

PHP Code:
<algorithmdirtyregions>2</algorithmdirtyregions

The default setting for this is to update the entire screen anytime there is any change, so in the case of the spinner, update a small part of the screen or update the whole screen. I'm sure you can guess which would be quicker (and less load on the Pi).
This is not supported on the Pi (or ATV2 or any GLES platform as far as I know).

(2013-07-20, 18:27)wyrm Wrote: There is maybe another way to reduce the load on your system (that is if you are running a very recent build of Gotham), that is to reduce the maximum frame rate in the as.xml file. The XBMC GUI is rendered in a big game loop, so if you reduce the number of times the Gui loop is executed, your CPU load must go down.
There is a PR, but it's not accepted (and I doubt it will be). (https://github.com/xbmc/xbmc/pull/2265 )
This solution is not so good. I'm quite happy having a 60fps animation for 0.5 seconds when I switch screens.
I don't want a 60fps animation for 10 seconds when I'm waiting for something busy to complete.

(2013-07-20, 18:27)wyrm Wrote: As to replacing the animated image with a static image, how do you tell if your Pi has hung instead of just busy off doing something?
XBMC on my Pi doesn't really hang, so this doesn't concern me.
Reply
#22
(2013-07-20, 18:27)wyrm Wrote: The default setting for this is to update the entire screen anytime there is any change, so in the case of the spinner, update a small part of the screen or update the whole screen. I'm sure you can guess which would be quicker (and less load on the Pi).
I believe the default was changed to the be most efficient value some time ago. As you say the Wiki is down right now so I can't confirm but I'm pretty sure that once the Dirty Regions code was well proven it became the default.

(2013-07-20, 18:27)wyrm Wrote: There is maybe another way to reduce the load on your system (that is if you are running a very recent build of Gotham), that is to reduce the maximum frame rate in the as.xml file. The XBMC GUI is rendered in a big game loop, so if you reduce the number of times the Gui loop is executed, your CPU load must go down.

You can do this by enabling vsync, which helps limit GUI updates on systems like the Pi, although it's what I already have enabled so it still doesn't help much when something hammers on the GUI like the busy spinner.

(2013-07-20, 18:27)wyrm Wrote: As to replacing the animated image with a static image, how do you tell if your Pi has hung instead of just busy off doing something?

That's why I would suggest updating the screen (spinner) just once a second. Maybe twice a second if necessary. It doesn't need to be pretty, just informative and "cheap" in terms of resource usage.

Though to be honest, as my system is stable I haven't missed the animation at all, and am enjoying the significant improvement in performance which is very noticeable.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#23
I'm the one that asked about a static image. Personally I can live without any notification but the wife and kids are "button crunchers" and will continuously hit remote buttons if they don't know something is happening. As far as hanging, with a good power supply Pis don't hang.
If I have been of help, please add to my reputation as a way of saying thanks, it's free.
Reply
#24
You could re-code the busy dialog so that it appears very large in the middle of the screen with the text "Working! Don't mash them buttons!". You could even insert the name of wife+kids for extra freak-out value. Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#25
http://webcache.googleusercontent.com/se...clnk&gl=us
Reply
#26
Thanks Ned, so algorithm 3 (with 0ms flip) is the default.

I've just tried algorithms 1 and 2 (with 0ms and 1000ms flip) on a 1GHz Pi running OE 3.1.2 (Frodo, 12.2) and in all cases this algorithm is unusable.

Algorithm 0 works with both 0 and 1000ms flips, but the CPU is pegged at 90% while idle and with no obvious GUI activity.

Algorithm 3 allows the CPU to spin down to 25% when the GUI is idle, so is the best choice. This algorithm works only with 0ms flip - a 1000ms flip resulted in occasional blank screens. The busy spinner with this setting pegs the CPU at 90% (vsync enabled, 60Hz).

Undoubtedly a more efficient GUI update process would mitigate the overhead caused by the busy spinner, but unless future GUI updating is virtually for free in terms of CPU usage I don't see the point in wasting precious CPU cycles on a cosmetic visual just when those cycles are needed the most (ie. when the machine is "busy"). In which case on low powered machines don't update the GUI at all while busy, or if a busy visual is deemed necessary then update the GUI using as little resource overhead as is possible.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#27
I think there should be something to indicate the system is busy for longer than 5 seconds, maybe a row of dots that light up one by one every 5 seconds to make a row across the bottom of the screen. Or it could be the rotating spinner even, just with much slower rotation. This would significantly reduce the amount of GUI writes.

It's just a thought but having no indication at all will meet with grief from many people. Also having it as an option to turn off completely isn't a bad idea.
Reply
#28
I've brought this to pecinko's attention (who makes the Pi-friendly Amber skin).
http://forum.xbmc.org/showthread.php?tid...pid1468222

Looks like you can use an animated GIF for the spinner.
While that still causes a full screen refresh, with an animated GIF you can lower the update rate (e.g. to 2 fps) and get most of the benefit.
Reply
#29
An animated GIF sounds good, I wondered if there was a "step" option for the animation element that could be used to rotate the current spinner image 90 degress every 0.5-1 second but apparently not, however a GIF should be able to achieve a similar (or better) effect. Can't png's also be animated (apng?)

Edit: I downloaded your 2fps Loading.gif into skin.confluence.modified/media/busy.gif, commented out the animation in 720p/DialogBusy.xml and changed the texture from busy.png to busy.gif, and now "top" shows a CPU load of about 28% (~25% being the norm with _no_ animation) so that's pretty impressive - thumbs up from me! Smile
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#30
great improvement! To benchmark navigating channel listings or starting certain addons, this tip by Ronnie is very usefull too.
Reply

Logout Mark Read Team Forum Stats Members Help
Working...0