[MPlayer-dev-eng] [PATCH] cmov detection and draw_alpha fixes

[Ivan Kalvachev]

2006/3/31, Rich Felker <dalias at aerifal.cx>:
> On Fri, Mar 31, 2006 at 03:53:21AM +0200, Alban Bedel wrote:
> >
> > Hi,
> >
> > since i added the box backgrounds in the osd menu i noticed a nasty bug
> > with the draw alpha functions. They happily overflow leading to some nice
> > distortions :/ So i went on to fix that, the mmx version are trivial to
> > fix just change the final paddb to a paddusb. However for the generic
> > i386 asm for rgb24/32 i didn't found a nice and quick solution w/o
> > using cmov (their probably is or ?). So i used cmov and let the rest
> > fallback on C.
> >
> > Sadly cmov is not present on all cpu, currently it is only used in lavc
> > under a #if __CPU__ >= 686. However their are some 586 with cmov (for ex
> > the AMD Geode which is a 586 with cmov and mmx). So i added a proper test
> > to configure and cpudetect.c.
>
> This is all incorrect. There is no bug in the draw_alpha functions.
> Rather you are passing them incorrect data. MPlayer requires a special
> alpha format tailored to the optimizations used in the non-mmx code.

Indeed.

now let's say we have image pixles with variable "image" we have
bitmap pixel with variable "bitmap" and alpha for the same bitmap
called "alphamap", (all values are floats) so

newimage = image*alphamap + bitmap*(1-alphamap).

now, the (bitmap*(1-alphamap) depends only on the data from the
bitmap, not the data from the image. This means it could be
precalculated and stored. so:

newimage = image*alphamap + calcmap.

Now, if you have overflow you are most likely using "bitmap" instead
of "calcmap" or there is some kind of rounding error (e.g. for speed
reasons alpha 1.0 is 0xff not 0x100)

Hope this helps