[MPlayer-dev-eng] [PATCH] Direct3D libvo driver

[Georgi Petrov]

> Hm. If you want to support it just using the real 3D API instead of
> StretchRect might be nicer, except I guess that the 3D API would not
> support YUV.

I don't think that's a problem at all - StretchRect requires 2 RECTS -
source and destination. If you pass them as NULLs, it defaults to the
whole source/destination surfaces. In case of fullscreen I just pass a
RECT, which is subrect of the fullscreen in order to display the movie
height centered, but if I want to have panscan, I would pass source
RECT as well, which will be subrect of the original (movie) surface
cropped from all directions. If will be stretched on the same
destination surface as the fullscreen destination RECT.

I won't use the 3D API - I have everything I want in just those
functions I call so far :)

> Anyway, you still should not be using your own aspect code, it e.g. does
> not handle -monitor-aspect or even -monitor-pixel-aspect and probably
> even more issues. Just leave out the three lines relating to panscan
> and you should not have any issues (at least not more than with the
> current code).

I'll do it.

>> And why isn't DR turned on by
>> default for drivers that support it?
>
> Mostly bugs, but also because you can't really know if it will be
> faster (and that is a fundamental problem, it can depend e.g. on
> the memory access patterns of the decoder or video filter).
> DR is actually quite useless most of the time.
>

Great. I'll do it later. In case of D3D I don't loose anything,
because D3D's OffscreenSurface (where the decoder will render in case
or DR) is located in the main memory and not on video card's memory,
which will be slow to read. StretchRect copies OffscreenSurface's
contents to video RAM on StretchRect. Right now without DR the decoder
decodes once in RAM (mpi->planes), then I copy this content second
time in RAM (in OffscreenSurface's locked memory) and then on
StretchRect it is copied in video memory. We have one additional
unneeded RAM->RAM copy. So I don't see how DR might be slower in this
case...

However, I understand your rationale about memory access patterns of
the decoder or the video filter. I will implement it later and
experiment. This is relatively low priority.


> No, no ideas, though it sounds like a very weird approach to let the
> programmer handle the backbuffer themselves, sounds like useless
> complexity to me (not that OpenGL doesn't have its share of mess).
>

Yep - it's the way it is. I made a research and as far as I understand
you have to recreate the rendering context on window resize. Actually
it's not that painful - it's blazing fast on my PC (but this is wrong
argument and besides my PC is blazing fast as well) and you don't
resize that often. I can live with it :)

The only thing that comes to my mind is that on resize after I release
the OffscreenSurface, it might be faster to call Reset() with the new
presentation parameters than destroy the adapter and recreate it with
the new presentation parameters... I doubt someone will EVER notice
the difference and it will add additional checks which I don't think
are necessary.

>>     /* Copy U */
>>     Dst = stLockedRect.pBits;
>>     Dst = Dst + stLockedRect.Pitch * gSrcHeight
>>
>> I've done it that way and I hope that's correct.
>
> It was correct before, I was only complaining about the comment,
> which gave the wrong impression IMO.
> Feel free to write it in whichever way you prefer.
>

I've done it this way. No more casts, no warnings - everything is ok
now (I think).

Ok, something else? I'm looking forward to clean all the small
problems just to get the driver once accepted and the latest SVN clean
compiled and working, so I can continue to add features and fix
eventual problems with all changes to additional files in place. I
want to get to the point when I will submit only vo_direct3d.c changes
so we can work out the problems easier and faster :)