A proposed GUI lib improvement (1 Viewer)




I would like to propose an improvement to the GUI library in MediaPortal. It is not complicated to understand, but will impact many GUI elements so the changes required are significant...

The problem
MediaPortal currently renders its GUI based on a constant framerate. It tries to keep this frame rate by waiting for a certain amount of time after each frame. To know how much time to wait, a primitive increment/decrement of the wait timer value is used to try to compensate for FPS fluctuations. This is not a good way to render real time graphics in a multitasking environment such as Windows.

Not only does this method make it hard to create smooth movement, but it also complicates the code required to animate GUI elements since you have to bother with frame/speed/time conversions. I believe this is the source for MP's jerky scrolling and movement.

The solution
What I propose is to base the GUI rendering on the same principle that is used in all games and demos nowadays (afaik), and that is to use frame rate independent, delta-time based animations.

The technique is simple. In every call to Render() you supply the amount of time passed since the last frame was rendered. All animation calculations within the Render() method are then based on the elapsed time that was passed in.

This means that if you want something to move 10 pixels per second, you simply multiply 10 by the time that was passed in (provided the time passed in was in seconds). Just remember to keep everything in floats, i.e. the time passed in and the current position of the item you want to move. Always use floating point, and then round to integer when rendering to screen.

The same goes for anything you want to animate, from color blending to scrolling to 3D rotations...Everything becomes time based and will move at the same speed no matter if the machine is slow and running at only 10 FPS or a monster computer that runs it super smoothly in 100 FPS...

And also remember that the frame rate can be capped in order to free up CPU, if you want to trade GUI smoothness for more available CPU. Simply perform the same check as today and sleep if the frame rate is too fast. The difference is that the rendering is no longer tied to a wobbly frame rate, but a rock steady clock sync and animations with floating point precision...

I am not a DirectX expert (though I have some experience with it) but I have quite a lot of experience in real time graphics programming from many years of demo coding. I also have four years experience in C# development. I am willing to help out if you need me, though my spare time may be a bit limited at times...


Portal Member
October 6, 2004
This sounds pretty good... but I have another suggestion.

Only call render whenever there is something to render.

For example, say you have a simple skin and on the home page you have a dynamic clock showing the current time updated every minute. If there is no input, the clock is the only thing that changes, hence one call to render every minute. That sounds efficient.

Now cross that with your suggestions and you have a very performant GUI that uses as little cpu as possible.

Also, it would be nice if the skinning engine was built upon MyXaml.


Retired Team Member
  • Premium Supporter
  • April 27, 2004
    Leipzig, Germany
    Home Country
    Germany Germany
    Hi Vic,

    sound really good. Perhaps you can find the time to discuss your ideas on IRC. You can explain them to the main developers. I think they will be glad to hear such things. :)



    Retired Team Member
  • Premium Supporter
  • April 22, 2004
    any plans on this?

    (Personally, I have no performance problem with the current gui, just interested, because your proposal sounds so promising.)



    I agree that this would be a major improvement, especially for plugins that perform directx calls already, such as the animated background plugin that enables scrolling pictures over background, would make it able to be very very smooth


    Portal Pro
    February 18, 2005
    The Netherlands
    Apart from the performance thing this would also open doors for a UI enhancement in the form of 'skin-defined' timeline-based actions and object movements. That would really be something that can add to the user experience in my opinion.

    (No, I don't really have any programming skills, but yes, I'm willing to help out. ;-) )

    Users who are viewing this thread

    Top Bottom