home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
A proposed GUI lib improvement
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Vic" data-source="post: 10783"><p>Hello,</p><p></p><p>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...</p><p></p><p><strong>The problem</strong></p><p>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.</p><p></p><p>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.</p><p></p><p><strong>The solution</strong> </p><p>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 <strong>frame rate independent, delta-time based animations</strong>.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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...</p><p></p><p></p><p>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...</p><p></p><p></p><p>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...</p></blockquote><p></p>
[QUOTE="Vic, post: 10783"] 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... [b]The problem[/b] 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. [b]The solution[/b] 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 [b]frame rate independent, delta-time based animations[/b]. 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... [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
A proposed GUI lib improvement
Contact us
RSS
Top
Bottom