[Bernd]

I think the high CPU usage on idle is an issue of the way XBMC is implemented.

Here is my theory:

Normal programs (like notepad) are so called event-driven. That means normally they wait until the OS sends the application an event (key-press, mouseclick, etc). It then processes that event and waits for the next event.
This is why notepad doesn't utilize any CPU when idle, it just waits until something happens.

XBMC in contrast has a active running Execution-Loop. It actively paints/displays the GUI according to the skin, checks whether the mouse has been moved or any key as been pressed, etc and then loops and paints the next frame.
Because as soon as all work for one frame is done XBMC starts over rendering the next frame and there isn't any waiting involved. That is why you get higher frame rates on faster machines.
But having high frame rates also comes with price of high CPU utilization.
This is not a bug!

I think when you turn on wait for VBlank option, this introduces some waiting into the loop. The system is then instructed to wait until the display device has finished drawing the display of one frame.

In my XBMC installation I noticed high CPU utilization when playing audio. In the settings you can limit the frame-rate for visualization. Setting this to 25 greatly reduced CPU utilization when playing audio and using visualization.

I don't know whether there is an option to limit the frame rate for the menus?
This may reduce CPU utilization.

Bernd

[m.savazzi]

I think the high CPU usage on idle is an issue of the way XBMC is implemented.

Here is my theory:

Normal programs (like notepad) are so called event-driven. That means normally they wait until the OS sends the application an event (key-press, mouseclick, etc). It then processes that event and waits for the next event.
This is why notepad doesn't utilize any CPU when idle, it just waits until something happens.

XBMC in contrast has a active running Execution-Loop. It actively paints/displays the GUI according to the skin, checks whether the mouse has been moved or any key as been pressed, etc and then loops and paints the next frame.
Because as soon as all work for one frame is done XBMC starts over rendering the next frame and there isn't any waiting involved. That is why you get higher frame rates on faster machines.
But having high frame rates also comes with price of high CPU utilization.
This is not a bug!

I think when you turn on wait for VBlank option, this introduces some waiting into the loop. The system is then instructed to wait until the display device has finished drawing the display of one frame.

In my XBMC installation I noticed high CPU utilization when playing audio. In the settings you can limit the frame-rate for visualization. Setting this to 25 greatly reduced CPU utilization when playing audio and using visualization.

I don't know whether there is an option to limit the frame rate for the menus?
This may reduce CPU utilization.

Bernd

This could be a good explanation but it means that XBMC does not use the "correct" instructions to free the CPU during the wait cycles.

I mean, is fine if it is repainting or other stuff.... but if it is waiting for a refresh the CPU should be free for another process.

[WiSo]

Guys this topic has been discussed several times (search for it).
Due to its origin XBMC is running in a game loop with 60fps when vsync is on (depending on the monitor) and "unlimited" when vsync is off.
This ofc uses more CPU cycles than a "normal" Windows app as Bernd described. Another problem is that some drivers - especially when using OpenGL for Windows - max out the CPU when waiting for the vsync.
You can easily profile the root in the driver and not XBMC for this case.

Lowering the fps in the menus helps ofc but make the rss feed choppy. To be honest I'm also not happy with it as it turns on the fan on my htpc. So I "hardcoded" some lower fsp into the gui which helps reducing CPU load but makes the rss looking ugly which I really don't care.

[m.savazzi]

Guys this topic has been discussed several times (search for it).
Due to its origin XBMC is running in a game loop with 60fps when vsync is on (depending on the monitor) and "unlimited" when vsync is off.
This ofc uses more CPU cycles than a "normal" Windows app as Bernd described. Another problem is that some drivers - especially when using OpenGL for Windows - max out the CPU when waiting for the vsync.
You can easily profile the root in the driver and not XBMC for this case.

Lowering the fps in the menus helps ofc but make the rss feed choppy. To be honest I'm also not happy with it as it turns on the fan on my htpc. So I "hardcoded" some lower fsp into the gui which helps reducing CPU load but makes the rss looking ugly which I really don't care.

WiSo,
is the FPS impacting the playback of video or just RSS and animations?

[WiSo]

It's just impacting the GUI (rss and animations). video playback is controlled by the dvdplayer and not set to a fixed fps ofc.

[hentar]

May you please convert your hardcoded GUI fps hack to some conf. value at advancedsettings xml?

I'd be nice to have this option, honestly I'd prefer to torn off th RSS stuff on my system if that's the whole problem

[sealight]

Due to its origin XBMC is running in a game loop with 60fps when vsync is on (depending on the monitor) and "unlimited" when vsync is off. This ofc uses more CPU cycles than a "normal" Windows app as Bernd described.

XBMC is not event driven? It repaints on every frame?

Still I'm sure some workaround can be implemented such as on Idle CPU will have near 0% usage.

May you please convert your hardcoded GUI fps hack to some conf. value at advancedsettings xml?
I'd be nice to have this option, honestly I'd prefer to torn off th RSS stuff on my system if that's the whole problem

+1
How can we set menu fdp?

[fowie]

Thanks @WiSo, but if you noticed, I mentioned in the first post that I'd searched and searched, and although there is a lot of information in this forum, I never got a straight answer. It was always "With an ATI card, turn off VSYNC" and "With an NVIDIA card, do this..." but I have an Intel card. That hack to lower FPS on the main screen sounds exactly like what I'm looking for, but every team developer that responds to me says the exact same thing you said, "It's been posted". Problem is, I can't find it. Apparently neither can anyone else on this thread, or someone else might have posted that already. Do you have a link to the exact post? Could you post your hack to lower FPS? Thanks for replying.

[WiSo]

XBMC has it's origin on the XBOX which renders in a game loop and thats the whole story. If someone wants to change it please go ahead but it might be a huge rewrite.
@sealight: we are open for suggestions so please let us know your thoughts for workarounds.

The hack is just to limit the frame rate to 30 fps which is simply changing one value in application.cpp. I don't think the other developers would like to see it as an advanced settings option.

All other tips regarding vsync and driver settings may also help in certain circumstances. I've seen the CPU load being lower when rendering 100fps than with vsync turned on and 60fps just because the driver ate CPU. Also the threaded optimisation of the Nvidia driver is/was an issue.

[sealight]

XBMC has it's origin on the XBOX which renders in a game loop and thats the whole story. If someone wants to change it please go ahead but it might be a huge rewrite.
@sealight: we are open for suggestions so please let us know your thoughts for workarounds.
(...)

I don't know the code but wouldn't it be possible to detect the idle state (no animations running, no mouse or key interaction) and leave the loop?
Then attach an event handler to mouse ou key input and re-enter the loop when these events are triggered.
CPU usage on idle state doesn't make much sense.

[WiSo]

The detection is already in see the screen savers for example. afaik the black one lowers the fps too.
It's not detecting the state but what to so then? Lowering the fps is the only thing I can think of yet but this would come up with another bunch of complains regarding sloppy animations

[m.savazzi]

WiSo,
I agree with you that changing the paradigm from execution loop based to event driven is not a minor change but a big major.
Plus it will create two different branches from XBOX and all the rest.

The questions are:
1) there are already two heavily different versions?
2) is it worthy to change on pc (or everything apart from XBOX) to event driven? apart from CPU which could be the advantage?

[WiSo]

We are already far away from the xbox branch so that isn't a point. Its more a matter who will do it and is it worth. This question needs to be answered by a senior dev ...

[fowie]

@WiSo: Thanks for the suggestions. I'd love to help contribute and make this easier for someone else to find in the future, where in the FAQ (or somewhere else?) could I put this information?

[m.savazzi]

We are already far away from the xbox branch so that isn't a point. Its more a matter who will do it and is it worth. This question needs to be answered by a senior dev ...

This is a very good information so now we have to identify the advantages.