[MPlayer-dev-eng] Writing a brand new D3D video output to fix Vista Aero disabling

[Georgi Petrov]

Thanks again to everybody. It was interesting reading you thoughts.

What's helping me most is VLC's D3D video out. It's really good
written and I think it is sufficient. Now I have window, with
initialized (more or less) D3D instance inside, with forced YUY2
format by myself (detection of HW caps will happen a little bit later)
and I'm really close to the moment, when I will start putting real
frames into this window.

I'm sorry I write a bit of nonsense and spam-like posts, but this is
my way of taking a break. In a few days I'll have some real questions,
but as I see - you guys really know what's going on, so you will be
able to help me :)

compn, if you are interested, you can check VLC's "direct3d.c", it's a
hell of a driver! Everything is really clean and good structured. It's
my inspiration. I understand most of mplayer's own DirectDraw
vo_directx.c and mixing those two together help me a lot. I also peek
at vo_gl.c for ideas and comparisons to vo_directx.c.

Never, NEVER forget how good thing open source is!!! If I had to do
this alone without any code to take a look at or anyone to ask, I
would never succeed.

Pixel shaders are too complicated for me. I don't really think we are
going to need them, but I still haven't reached so far. I think that
the most important surfaces IMHO - YV12, YUY2 - are supported without
additional things to do.

Hey, Reimar, I really love that you made vo_gl.c available for windows
as well. I think I won't be able to beat it anytime soon, but I really
like to have something to compete with. It's more fun this way. You
know that having one video rendered is faaaar away from having a
complete driver. I'm still away even from this "one video rendered"
moment and I see how many things must be supported in order to
consider a libvo driver complete. I won't be there many months to come
:)

Hopefully when I have something working, I would be really interested
to comparison between directx, d3d and gl. Not from point of "who's
driver is better", but from pure technological aspect. Doing something
by using different APIs is always interesting source of comparisons.
For example I want to contribute back to directx's driver the
rendering of subtitles AFTER scaling, which would be really great.
After all - we are helping each other :)

>Well, I can't resist to say: That is just Microsoft being lazy though,
>to my knowledge X can support xv with compositing, and at least Xgl
>could do it in a way that integrated without problems.

May be they are. Yes, X can support XV with composition, but sometimes
there are HW limitations. Let me give you an example - when I had
Geforce 4 MX440 (Geforce 2 internally, DX7 class HW), when I used
compiz through nVidia's first driver to support
GLX_texture_from_pixmap, the XV video was not accelerated because this
Geforce couldn't do it in HW (I don't remember the details). I got
accelerated XV when NOT using compositing, but using compositiong AND
XV resulted in SW colorspaces conversion (as I recall). I borrowed a
Geforce FX5200, which is DX9 class HW from a friend of mine and XV
video + compositing was accelerated. From the first time I plugged the
video card, it was accelerated with close to zero CPU usase. As
normal. No problems at all. On my GF4 it wasn't.

In this story it was about HW not capable of something. In Vista it's
different. Here we have one interface (DirectDraw) not compatible with
desktop compositing. I'm not sure if there is a technological
limitation behind it. There might be, there might be not. But as far
as I know GDI isn't accelerated anymore on Vista, so I don't know if
they have something in common with DirectDraw that might be the cause.

In the end I'm happy that you are ready to help and right now I may
not be very interesting, but in a couple of days I will have really
important questions!