[MPlayer-dev-eng] Direct3D OSD discussion

[Jim Hauxwell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

New patch which fixes some main issues with the last patch.

1) rendering is performed with no latency.  drawn between the
stretchblit and the present.

2) uses a L8A8 texture for the osd, so is correctly alphablended.
note that even the gl driver has to map the inverted alpha value using
software memory copy (line ~551 in vo_gl.c).  It should be possible to
come up with a better way to do this.  Please be aware that although the
code may use a glTexSubImage2D() for upload the chances are this is SW
in the driver.  It will use less memory bandwidth than the gl version as
the gl version has no alpha test to reduce GPU loads from the
framebuffer and its a two pass version.

3) The image is only rendered once and then presented multiple times if
it does not change.

4) If no osd are visible on then there is no cost (well a few branches :-) )

I think that this addresses most of the issues.  I think the main
outstanding one will be the SW rendering of the subtitle to the texture.
 This is however a saving over a pure SW solution as the osd doesn't
need to be continually blended with the changing video underneath.

Like I say I may come up with a better way for texture upload in the
next few days, but I think its OK for now.

Jim

> Hello,
> 
> I prefer to move all OSD questions/answers in this thread, because
> we're over with D3D's performance for time being.
> 
> First of all - Jim, thanks for updating to the latest SVN version and
> posting patches relative to it - it saves us all :) Let me ask some
> questions:
> 
> 1. Drawing on the next frame is fixed easily I think. I'm sure Jim
> will do it right.
> 
> 2. What bothers me more is this:
> 
>>>>>> 2) OSD is rendered in software first and then once more in hardware
>>>> Again does the same as the gl renderer.
>>> You use vo_draw_alpha_rgb32 which does alpha blending and more in
>>> software. vo_gl does not.
>>>
> 
>> I will look into this.
> 
> Hmmm, I have 2 questions: Why are all other drivers I looked into
> (like vo_directx.c) using vo_draw_alpha_xxxxx? This is supposed to be
> "software rendering", right Reimar? I mean - you give a texture of
> some size to the functions and tell in its colorspace and it draws the
> OSD for you? Additionally as I see the vo_draw_alpha_xxxxx has
> MMX/SSE/whatever optimizations and they are used when supported. What
> would be the "hardware" rendering? I can't really understand what is
> vo_gl.c doing different...
> 
> vo_gl calls vo_draw_text() with a parameter "create_osd_texture".
> Inside "create_osd_texture" you seem to "walk" through every OSD
> "part" and what... generate texture for each one?
> 
> Or better - vo_draw_text() calls "create_osd_texture" for every OSD
> element and "create_osd_texture" creates texture for it and places it
> somewhere, so finally everything gets "blended" on the backbuffer?
> Please excuse my prehistoric understanding about everything - my day
> job is writing software for network adapters :) :) :)
> 
> Are those things explained somewhere, so you can spare your words
> explaining what's happening? I'm ready to read literature about it...
> 
> The second question: why do you use vo_draw_alpha_rgb32? Because you
> create a texture with the same format as the backbuffer? This means
> that you DON'T "blend" the OSD with the movie's original offscreen
> surface and then StretchRect it on the backbuffer, but you render the
> OSD on a texture with the same format as the backbuffer and blend it
> independent from the offscreen surface of the movie?
> 
> BTW, I committed a patch for enabling BGR32/16/15 a few hours ago, but
> this is related to the format of the offscreen surface.
> 
> Another question: Why does vo_directx.c have support for:
> 
> vo_draw_alpha_yv12
> vo_draw_alpha_yuy2
> vo_draw_alpha_rgb15
> ....
> and so on?
> 
> I think that it does blend the OSD in the equivalent of the offscreen
> movie source surface or just when using Overlays, the backbuffer
> itself is equal to the movie's source format and you have to render
> the OSD in YV12, YUY2 or whatever your movie uses...
> 
>> Sorry, I misunderstood.  It redraws for each frame whilst it is on.
>> I'll fix this.
> 
> Does it mean that you must render the OSD in a texture on the first
> requested frame and just blend it until OSD is on (and haven't
> changed), so you don't render the OSD without need to do so on every
> frame (and use the already rendered instead)?
> 
> I'm sorry for my dumb questions. I'm trying to understand what's
> happening in the driver I originally wrote and only a week later don't
> understand anything :D
> _______________________________________________
> 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

iEYEARECAAYFAkkrOUkACgkQhrNWoHjgI1CeQgCbBnDDPkNm0GyT4R+726utCdYH
mdwAn0AT3nXHitLR1DK/Z3Pk4tkXZRrK
=HDb8
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff5.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081124/8f183966/attachment.txt>