[MPlayer-dev-eng] Direct3D OSD discussion
Jim Hauxwell
james at dattrax.co.uk
Wed Nov 26 01:26:37 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry,
Ignore the last one, I had forgotten to change the alpha test, the GPU
would have been doing more work than it needed.
Jim
> Hi Reimar,
>
> I was not aware of the reference code to do the osd blending, so I've
> taken a look at this and basically copied what it does.
>
> I've attached a patch which follows the exact blend rules
>
> ((dst * srca) >> 8) + src
>
> it uses a constant color to pass the multiplication for src, so its actually
>
> (1.0f * src) + (dst * srca) where srca is a float
>
> As a side effect you can change the color of the subtitles by changing
> the DWORD value in this line,
>
> IDirect3DDevice9_SetRenderState(priv->d3d_device, D3DRS_BLENDFACTOR,
> 0xFFFFFFFF);
>
> for red choose 0xFFFF0000, for example
>
>
> Jim
>
>
>> On Tue, Nov 25, 2008 at 06:08:04PM +0000, Jim Hauxwell wrote:
>>>> I don't think so. Also
>>>> + if(srca[x]){
>>>> + dst[x]=(~srca[x] << 8) | src[x];
>>>> + }
>>>> Why ~srca[x]? I think it should be -srca[x] (a quicker way of writing
>>>> ~srca[x]+1).
>>> No, I wrote what I wrote,
>>>
>>> -srca[i] gives the incorrect answer. If you take the value 0x0 then
>>> this gets transformed to 0x0 and not 0xFF which is the correct result.
>> Why do you think that 0xFF would be the correct result?
>> Due to the if, for your code the result is 0, too, btw.
>> Also, with your code, the final alpha value will never be 0xFF actually, thus
>> the OSD is never completely opaque.
>
>>> This is a bug in vo_gl.c, not my code.
>>>
>>> If you need a small test then I'll knock up the four or so lines to
>>> prove it.
>> Sure, prove it because I don't think it is a good way (without a
>> specification right and wrong is a bit difficult to say, the differences
>> are almost never visible).
>
>>>> Note that for blending that matches the other vos, one of your blend
>>>> settings should be D3DBLEND_ONE (the one that applies to the OSD
>>>> texture).
>>> Again, this is not a bug in my patch. The others vos (well gl anyway)
>>> uses a two pass blend, mine is a single pass, so this is the correct
>>> blending.
>> I can't see how single or two pass has any relevance (except that
>> vo_gl.c current implementation of two-pass can not do "correct"
>> alpha-blending due to discarding the alpha).
>> The point is that the OSD rendering formula for MPlayer (as seen in
>> osd_template.c) is:
>> if(srca[x]) dstbase[x]=((dstbase[x]*srca[x])>>8)+src[x];
>> (note that this is the C code which is somewhat broken, the asm code
>> does the clamping to [0,255] before writing back, it isn't noticed
>> usually because currently src is 0 when when srca > 1)
>> Alpha-blending as you do it is _not_ the same thing, e.g. if you do
>> for (int i = h * stride - 1; i >= 0; i--)
>> {
>> if (srca[i]) srca[i] = 0xff;
>> if (src[i]) src[i] = 90;
>> }
>> The effect will be different from anything you can get with
>> alpha-blending.
>> This is not important enough to justify a huge workaround, but I do not
>> see why it would be a good idea to make vo_direct3d's behave
>> different than all of the rest of MPlayer on purpose.
>
>> Greetings,
>> Reimar Döffinger
>> _______________________________________________
>> MPlayer-dev-eng mailing list
>> MPlayer-dev-eng at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
>
>
- ------------------------------------------------------------------------
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng at mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkksl70ACgkQhrNWoHjgI1CRAgCgymC+u3iEgp6FTjLfitFTE/VI
q5UAn3dfb63nUjapl1a6PSusT3Z5AgSV
=M3ao
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff8.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081126/8f661e0b/attachment.asc>
More information about the MPlayer-dev-eng
mailing list