[MPlayer-dev-eng] [PATCH] SwScaler YV12 to BGR32 having zeroed alpha

Michael Niedermayer michaelni at gmx.at
Mon May 30 00:31:14 CEST 2005


Hi

On Sunday 29 May 2005 23:57, Jason Tackaberry wrote:
> On Sun, 2005-05-29 at 23:02 +0200, Michael Niedermayer wrote:
> > if it would be clean, wont cause any slowdown and is preferably optional
> > then yes,
>
> Well there are a couple extra additions and shifts in C case, and a
> pcmpeqb instead of pxor in the MMX case, so it will naturally be slower,
> but I'd be shocked if it was measurable. :)
>
> I can't imagine a case where alpha being initialized to 0xFF would break
> anything.  Is there any existing code anywhere that relies on it being
> 0x00?  If there is, then I suppose it would have to be optional, and
> disabled by default.  But it would complicate the code quite a bit over
> what I'm attaching to this email.  Well, if that's the only way it would
> get merged, then I'll implement it that way.  But I think setting alpha
> the alpha to fully opaque is a more sane default.
>
> At any rate, the attached patch makes the alpha bytes 0xFF in SwScaler
> for unscaled and scaled conversions to BGR32 or RGB32 in both C and MMX
> cases.  All cases have been tested and work.  The only thing I'm not
> sure about in terms of cleanliness is the unscaled C case (yuv2rgb.c).
> The same macros are used for both 32bpp and 16bpp cases (DST1(i) and
> DST2(i)).  I'm adding (255 << 24) to the values.  This isn't really any
> problem since for the 16bpp case it will just overflow and not affect
> the value.  But perhaps a better solution would be to add another
> argument to the macro that's used for the 32bpp case.  I think it's a
> matter of taste, but let me know.
>
[...]

> Anyway, please review the patch and let me know of any necessary
> changes.

> -                       ((uint32_t*)dest)[i2+0]= r[Y1] + g[Y1] + b[Y1];\
> -                       ((uint32_t*)dest)[i2+1]= r[Y2] + g[Y2] + b[Y2];\
> +                       ((uint32_t*)dest)[i2+0]= r[Y1] + g[Y1] + b[Y1] + 
(255 << 24);\
> +                       ((uint32_t*)dest)[i2+1]= r[Y2] + g[Y2] + b[Y2] + 
(255 << 24);\

why not add the 255 into one of the r,g,b arrays, this would avoid the 
slowdown
(or add 85<<24 to all 3)



[...]
-- 
Michael




More information about the MPlayer-dev-eng mailing list