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

[Arpi]

Hi,

Hmm, interesting code, but far from perfect... :)
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.

> 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.
- 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)
- 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?)
  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:
    - just draw (TEMP)
    - save & restore original pixels
    - fill with given color
    - call external save & restore functions
- 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. although this renderer should optinally
  support colors. this renderer could do optimized orig. pixel
  saving/restoring too (based on alpha value).
  Maybe a generic font rendering engine could help a lot, so it could cache
  up font bitmaps, saher between osd objects, etc etc
- what about the spu and text (ascii) output/passthru ?
- how to pass text to be displayed to the osd objects from outside (eg. UI) ?


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu