I think XBMC has some fundamental problems with the GUI architecture.
From their FAQ:
"Why does XBMC use x% CPU usage while sitting idle?
XBMC was originally written for the XBox game console, which is a single-threaded system (not a multi-tasking OS like Windows). As such, it was written in a game loop, rather than being event-driven. This means that the screen refreshes as fast as possible in order to "feel" responsive to the user. What this boils down to is that while sitting on the idle screen, XBMC is still repainting the screen at 60-90 frames per second (as can be seen by the FPS number if debug mode is enabled). This takes up a lot of processor power, because the "game" is still running, even though you may not be doing anything with it.
There are currently no intentions to change this, as it is a very low-level change of the entire XBMC platform."
Mediaportal is being written in a much more modern and extensible way.
Ah, well at least things will be different with MP 2.Actually MP has just similar "game" loop that is constantly rendering the GUI for 50 fps (or the actual refresh rate of display device).
Ah, well at least things will be different with MP 2.Actually MP has just similar "game" loop that is constantly rendering the GUI for 50 fps (or the actual refresh rate of display device).
You need this for video but not for displaying the user interface or photos surely? You don't need to constantly tell the OS when something has stayed the same. (Of course the OS/videocard will repeat itself when it talks to a standard display.)There will still be a main rendering loop in the MP2, which is running at the speed of the display's refresh rate. This is how 3D applications work. Difference to MP1 (and maybe XBMC, not sure since I don't know their code base that well) is that the rendering thread wont be used for non-rendering work.