- March 26, 2007
- 3,715
- 180
- Home Country
-
Germany
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.
http://mantis.team-mediaportal.com/view.php?id=1974
Open the issue in Mantis...
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.
http://mantis.team-mediaportal.com/view.php?id=1974
Open the issue in Mantis...