Login at Kodi Home

dmcx · 2014-11-18, 23:04

iPad 2, iOS8.1

What would account for the difference in CPU use when playing the same local file?

.m4a music (cpu % from "top"):

XBMC 13.2: 70%
VLC 2.3.0: 9%

**Memphiz** · 2014-11-18, 23:11

audio visualisation?

dmcx · 2014-11-18, 23:18

(2014-11-18, 23:11)Memphiz Wrote: audio visualisation?

No visualization is active in XBMC.

**Memphiz** · 2014-11-18, 23:20

What happens if you start playback and then hit the home button (music will be paused then - go to control center and continue playback from there). I am not quiet sure what the goal of your question is - we all know that XBMC/Kodi sucks CPU as much as it can for multiple reasons. (gui rendering like a gameloop for example).

**Memphiz** · (This post was last modified: 2014-11-18, 23:26 by Memphiz.)

Just checked . Kodi b3 running on ipad2 (ios 6.1) playing an m4a testfile visualisation off - no OSD controls visible (bascially the black rendered screen):

39382 Kodi 9.2% 0:50.54 19 125 0 0 0 66M 515M

Bringing the OSD up increases it to 16 %

back to gui 19%

back to home screen 75% (because of the rss feed ticker).

dmcx · (This post was last modified: 2014-11-18, 23:33 by dmcx.)

(2014-11-18, 23:20)Memphiz Wrote: What happens if you start playback and then hit the home button (music will be paused then - go to control center and continue playback from there). I am not quiet sure what the goal of your question is - we all know that XBMC/Kodi sucks CPU as much as it can for multiple reasons. (gui rendering like a gameloop for example).

Starting full screen visualization while playing the m4a makes the CPU go down to 35%.
Tapping the full screen visualization so the header/footer of the skin display makes it go back up to 55%

Going to XBMC home screen goes to 60%.
Re-opening Music File list makes it go back up to 70%.

Clicking iPad Home button and resuming playback from CC & CPU use goes to 13%. Pausing from CC and XBMC goes down to 1.5%

Seems like the skinning is killing it.

Back in XBMC, Stop the playing and XBMC is down to 8 or 9%. It was 8% when first starting up.

Re-touched skin, but is the same with Confluence.

(I have RSS off)

**Memphiz** · 2014-11-18, 23:34

yeah so what? as said - i get 9% when disabling viz and having osd hidden - you should be able to do the same.

dmcx · 2014-11-18, 23:39

(2014-11-18, 23:34)Memphiz Wrote: yeah so what? as said - i get 9% when disabling viz and having osd hidden - you should be able to do the same.

Selecting the None visualization (black screen) and CPU use is 14% while playing.

As I said, skinning (updating the controls -- ie: should the button be play or pause) must be hammering CPU.

**Memphiz** · 2014-11-18, 23:42

yes it does. Thats why i tested fullscreen without the osd controls visible (2finger swipe left to hide those - or wait and it should autohide).

**Memphiz** · 2014-11-18, 23:45

Before this discussion gets any longer. I really discussed this alot already for different platforms.

Its not a good comparision to compare a native ios app (vlc) which uses the OS GUI rendering with XBMC/Kodi. XBMC/Kodi is a full blown opengl app with its own GUI(from scratch!) which runs on a game loop ported over to gles. It is not ment to be low CPU - it is not ment to have a low impact on your battery. Hell even the fact that it runs on any battery driven touch device is just by accident. The Focus is on set-top boxes or other appliences connected to a TV (and to a power cord). Having it on 14% with the osd control is already a good result for this design.

dmcx · 2014-11-19, 00:01

Ok.

But when a 3D Spectrum Visualization takes up less CPU than a skin with buttons doing nothing ... hrmm. Makes one wonder. Smile

**Memphiz** · (This post was last modified: 2014-11-19, 00:13 by Memphiz.)

Yes that would make me wonder too if i wouldn't know that there are reasons because of the difference of rendering colored bars and something like the gui (a big bunch of vertices). But believe me even if i am not the GUI/gl guy - the pros in this area tweaked alot allready and thats pretty much what the current design/codebase will do on gles. (rbpi is the best example where the whole render stuff was tweaked for - ios benefitted from this already).

I also fully accept the "this must be possible to optimize - what the fuck do they have for slow code in there" attitude which creeps up when one just looks at the results as an outside dev. Its just tiring to discuss it every few moths Wink

dmcx · (This post was last modified: 2014-11-19, 00:30 by dmcx.)

(2014-11-19, 00:11)Memphiz Wrote: Yes that would make me wonder too if i wouldn't know that there are reasons because of the difference of rendering colored bars and something like the gui (a big bunch of vertices). But believe me even if i am not the GUI/gl guy - the pros in this area tweaked alot allready and thats pretty much what the current design/codebase will do on gles. (rbpi is the best example where the whole render stuff was tweaked for - ios benefitted from this already).

I also fully accept the "this must be possible to optimize - what the fuck do they have for slow code in there" attitude which creeps up when one just looks at the results as an outside dev. Its just tiring to discuss it every few moths

You don't need to defend it -- perhaps there is an existing thread which reveals the details that you could link?

The goal might not be low cpu/energy use, but it couldn't hurt. Low cpu & amazing customization aren't necessarily mutually exclusive things.

It just reminds me of the little old lady in the 10 passenger SUV, and when Winamp changed their skin engine (for the worse, and had to revert).

Efficiency & low energy is the future Smile

**Memphiz** · (This post was last modified: 2014-11-19, 11:06 by Memphiz.)

I can try to get a former dev involved here (for describing the concept and restrictions). But only if you really intent to work on something like performance for Kodi. Its to much hazzle to wake up sleeping/retired people just for an "fyi". Sry. For FYI you would need to dive into the code and debugger/performance analyser and figure out where the penalties come from. (one thing is that we have a "dirty rendering" algorithm but on gles it only works by rendering the whole screen if only one pixel changes - dirty region is not possible (don't know the details - something missing on gles).

Its not ment to be rude - but we are in the final phase of the rebrand/release (nerves are really thin because of multiple internal problems which we have to solve) and we are really low on human ressources and time. I know this is not ideal and mostly scares devs away (which is the opposite of what we would need atm) - but its just a to big project to know all the internas and have them described in an easy understandable way.

Also while there are possibilities to make it better for gles you still have to keep in mind that the whole render stuff is really abstracted for all our platforms (gles, gl, directx, directfb what not) - so this restricts optimal pathes for sure.

We would welcome a "metal" renderbackend for sure Big Grin

So if you are a gles pro or otherwise ios / osx guru and wanna work on something big (and have way to much free time and are bored most of that time Big Grin

) - start hacking on something you like - develop it up to a pull request on github - do it good - become a team member Wink

Some bones for the gui render impl.:

https://github.com/xbmc/xbmc/tree/master/xbmc/rendering