[MPlayer-dev-eng] Direct3D OSD discussion

[Georgi Petrov]

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