V
Vic
Guest
Hello,
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...
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...
Germany
