[MPlayer-dev-eng] [PATCH] OSD through EOSD

[Reimar Döffinger]

On Fri, Aug 13, 2010 at 12:04:56AM +0200, Nicolas George wrote:
> > Not to mention the reason for why the alpha is the way it is
> > and why chroma is not touched (performance).
> 
> I am pretty sure too that transparency + premultiplied value is better,
> performance wise, than opacity + raw value. But just for readability's sake,
> do not call it alpha or a if it is not alpha.

What else to call it? It is alpha, it just has a special optimized
representation.
And the value is not pre-multiplied, it is clamped to avoid overflow.

> > 2) The osd actually does source * alpha + color, I don't think
> >    this can be 100% reproduced with EOSD (not that it may be a good
> >    idea, however I suspect that calculation is more complicated
> >    than necessary).
> 
> Indeed, "source * k + c" is more expressive than "(1-a) * source + a * value",
> since c can overflow while a * value can not. But AFAIK, the current OSD
> code does not use it.
> 
> I have tested my patch: the timestamp/message, the text subtitles and the
> progress bar are correctly displayed. I can not test every variant of SPU
> and cousins, but they come from "real" alpha channels, so they should not
> overflow.

As said it does not overflow due to explicit clamping.
This means the current blending is actually incorrect for most cases.
Which is why I said that it may not be a good idea to try to match
the OSD behaviour too much, still this should be a difference.
And it is also why I think your method of calculating dm is
over-complicated: I involves one division per without (I think)
actually gaining any accuracy over e.g. v == a ? 255 : v.