[MPlayer-G2-dev] Re: OSD, again :)

[Alban Bedel]

Hi Arpi,

on Mon, 21 Jul 2003 00:08:43 +0200 you wrote:

> Hi,
> 
> Hmm, interesting code, but far from perfect... :)
Sure :)

> Actually a better description of how objects are related and what is the
> purpose of them, maybe telling me/us how does rendering subtitles and
> osd symbols will eb done using this API would explain it better than
> RTFS.
hmm, RTF vo_osd.c :) A display is createad/exported by vf/vo/whatever
(if needed it add some area). Finnaly the clients (main app, subtitle
renderer, etc) create the objects they need and attach them to the
display. The clients should only deal with the objects. Settings specific
to an object type (like setting the current string to display) will
probably go through control.

> > The system is based on what i called "osd display". The display role
> > is to manage draw/clear of the various objects currently attached to
> > the display. Once a display is configured then you just feed it with
> > some mp_image and it will draw the objects.
> > The "osd display" doesn't do any drawing/clearing. It just take care
> > of what have to be done, draw are handled by the object themself, and
> > clear by a callback.
> > The system make the drawing/clearing decisions upon the "buffer type".
> > The display itself have a buffer type but it's also possible to define
> > some area with a different buffer type. There is 3
> > buffer types :
> 
> I like the basic idea, but:
> - it shouldn't mess with mpi. NEVER!
>   it will be used on non-mpi surfaces too, like vo buffer, lcd device
>   or spu encoder, or vo_dvb's osd buffer.
This is discutable :) mpi is nice atm bcs it can handle pretty much any
kind of data, and we alredy have some useful helper for it :)
Anyway if we darsticly reduce the number of colorspace then, yes
mpi doesn't make that much sense. However if draw might be done in planar
YUV i still vote for the mpi bcs it's nice for the object writer.

> - there should be per-area (and not per-display) draw & clear functions
>   (the purpose of multiple areas in a display to handle areas with
>   different behaviour - so allowing different funcs is trivial)
Draw is currently done directly by the object, clear is per display.

> - instead of TEMP/STATIC/LOCKED types (btw why is buffer_type in both
>   display and area structs? i guess the display one is obsolete/unused?)
It's the type of the "root", ie object wich doesn't fall in any area.

>   there should be save and restore modes, describing how to do these:
>    save modes:
>     - just draw (it's TEMP)
>     - save original pixels before draw
>       (if the osd object doesnt support this, we should save whole area)
>    restore modes:
>     - no need to restore
>     - fill with given color
>     - call external clear function
>     - restore saved original pixels
>    maybe it's better to combine single mode parameter... so:
yes
>     - just draw (TEMP)
>     - save & restore original pixels
>     - fill with given color
>     - call external save & restore functions
ok

> - rendering: we should add a generic luma+alpha osd renderer (like in
> g1), so
>   simple osd objects could use that. supporting many pixel formats in
>   every osd obj is nonsence and big work. 
I think you'r right on this. And anyway we need to cache the drawing so
it doesn't really make sense to draw directly on the target buffer.

>   although this renderer should
>   optinally support colors. this renderer could do optimized orig. pixel
>   saving/restoring too (based on alpha value).
So we must define wich colorspace we support. Obviously 8bit gray + 8bit
alpha like in g1, 8bit char for ASCII. For color dunno, 24bit RGB + 8bit
alpha, or do we go for YUV + alpha too ?

>   Maybe a generic font rendering engine could help a lot, so it could
>   cache up font bitmaps, saher between osd objects, etc etc
That would be nice. I have to look but i think freetype have some caching
stuff. That's perhaps enouth ?

> - what about the spu and text (ascii) output/passthru ?
Text output make only sense when the object drawing function support
it imho. For the rest we can try lib aa,conversion but i doubt it will
really work :)

For spu i don't really know. We must output the osd to an encoder
and then pass the coded stuff to the vo. So we probaly need yet
another interface for these encoders.
For real passthru (ie only dvd subs "as is") we just get rid of all this
crap and pass the packets from the demuxer right to the vo :)
Ok, we need to process these packet a bit before passing them to the vo
ircc. But imho i don't think that we should bother with that here.

> - how to pass text to be displayed to the osd objects from outside (eg.
> UI) ?
control :) A more important question is how will it iteract nicely with
the subtitle chain ? Well the subtitle chain is still to be defined ;)
	Albeu
-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.