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
Quality Assurance
Bugtracker Feed
0001974: Ensure responsiveness of GUI at any time
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="MediaPortal-Bot" data-source="post: 647760" data-attributes="member: 48617"><p>tourettes asked me to create a report for this, so here we go:</p><p></p><p>MPII should be designed in such a way, that its GUI stays responsive under all circumstances. This means that there should be different threads (that do not block each other ofc) for all background tasks.</p><p></p><p>Following requirements have been identified:</p><p></p><p>1) GUI must react to user input as fast as possible (< 0.1s), if only by showing some kind of _smoothly_ animated progress thingy in any given situation.</p><p></p><p>2) Anything other than GUI rendering (loading lists like the EPG, large directories, ....) must be done in a seperate thread, which must not block the GUI.</p><p></p><p>3) The optimal way would be to load lists progressively. i.e. show an empty list and the rest of the skin elements, and fill the data in on the fly. again, show some progress thingy until everything is loaded.</p><p></p><p>4) Slow video must not slow down the GUI. this is a bit tricky to achive, but e.g. in MP1 using animations for the Pause menu is a mess. it will wait for some time for video input (there is none, the video is paused after all), and not refresh the GUI in the meantime. when MP finally detects that there is no new video frame, the animation is already halfway done, and to the user this just looks like stuttering. this can ofc be worked around, but it will always be badly designed in the first place.</p><p></p><p>To do all of this in a predictable and controllable way, the thread handling must be done by the core, and no plugin should have to create threads for this themselves. a plugin should be forced by design to seperate data acquisition from presentation, and progressive updating should be taken care of automatically.</p><p></p><p><a href="http://mantis.team-mediaportal.com/view.php?id=1974" target="_blank">http://mantis.team-mediaportal.com/view.php?id=1974</a></p><p></p><p><a href="http://mantis.team-mediaportal.com/view.php?id=1974" target="_blank">Open the issue in Mantis...</a></p></blockquote><p></p>
[QUOTE="MediaPortal-Bot, post: 647760, member: 48617"] tourettes asked me to create a report for this, so here we go: MPII should be designed in such a way, that its GUI stays responsive under all circumstances. This means that there should be different threads (that do not block each other ofc) for all background tasks. Following requirements have been identified: 1) GUI must react to user input as fast as possible (< 0.1s), if only by showing some kind of _smoothly_ animated progress thingy in any given situation. 2) Anything other than GUI rendering (loading lists like the EPG, large directories, ....) must be done in a seperate thread, which must not block the GUI. 3) The optimal way would be to load lists progressively. i.e. show an empty list and the rest of the skin elements, and fill the data in on the fly. again, show some progress thingy until everything is loaded. 4) Slow video must not slow down the GUI. this is a bit tricky to achive, but e.g. in MP1 using animations for the Pause menu is a mess. it will wait for some time for video input (there is none, the video is paused after all), and not refresh the GUI in the meantime. when MP finally detects that there is no new video frame, the animation is already halfway done, and to the user this just looks like stuttering. this can ofc be worked around, but it will always be badly designed in the first place. To do all of this in a predictable and controllable way, the thread handling must be done by the core, and no plugin should have to create threads for this themselves. a plugin should be forced by design to seperate data acquisition from presentation, and progressive updating should be taken care of automatically. [url]http://mantis.team-mediaportal.com/view.php?id=1974[/url] [url=http://mantis.team-mediaportal.com/view.php?id=1974]Open the issue in Mantis...[/url] [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Quality Assurance
Bugtracker Feed
0001974: Ensure responsiveness of GUI at any time
Contact us
RSS
Top
Bottom