[MPlayer-dev-eng] Architectural TODO items

[Uoti Urpala]

On Sat, 2007-06-09 at 21:34 +0200, Benjamin Zores wrote:
> Uoti Urpala a écrit :
> > 1) Execute commands independently of frames / associated OSD issues
> > 
> > There are several reasons why running user/slave commands independently
> > of frame updates and without forcing unpause would be useful. The
> > "running commands" part should actually be pretty easy to implement; the
> > problematic part is OSD updates. MPlayer does not have a good UI
> > interface that could show information independently of frames.
> 
> We've been talking about a rewrite/enhancement of libmenu in order to 
> have a fancy UI and indeed, a first start would be to be able to draw it 
> independantly of framerate.
> 
> And as you've said another big issue is the OSD itself which sucks a 
> bit. A first effort might be addressed against design of a good libosd.
> Currently, iirc there's not even way to have colored DVD subtitles.

In a bit more detail the functionality I'm thinking about is as follows:
1) vo can draw OSD in a buffered frame before flipping (as implemented
   already in common vos)
2) new functionality: vo can update OSD content to match new state
3) new functionality: vo can add/change OSD content in the currently
   visible frame too, not just the buffered-for-flip one

Implementing 2) requires handling outdated content present in the frame
somehow. Some alternative ways to handle this (implementing all could
make sense as they have different tradeoffs):
- Keep a copy of the original image below rendered OSD parts. Has a
(probably minor) extra performance penalty when OSD is active.
- Render the OSD with opaque background instead of alpha and cover the
old version with that. Somewhat ugly.
- Only update OSD content immediately when MPlayer is completely paused,
and in that case keep a copy of the original image parts; if not paused
do not update OSD until the next frame.

When updating the currently visible buffer directly in 3) I think it's
OK to ignore double buffering.


About implementing "a fancy UI" in libmenu, I don't really like that
approach; I'd prefer implementing a good UI using a proper GUI toolkit
rather than building (necessarily inferior) custom widgets in MPlayer.
Though if you want to work on it it probably won't hurt anything else...


> Jason Tackaberry (from Freevo) also send somes patches that provides an 
> overlay over video (vf_bmolv2 replacement) some time agos and some ideas 
> might be taken from there to actually be able to design this osd/overlay 
> library.

At least the part implementing frame-independent updates was badly done
in the patches that were sent to mplayer-dev-eng earlier.