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

[Reimar Döffinger]

On Tue, Nov 18, 2008 at 04:52:55PM +0200, Georgi Petrov wrote:
> You have some very good points...
> 
> > 1. The w32_common documentation part should be separate from the vo_direct3d patch and probably committed right away.
> 
> It got committed already - everything - the driver and the changes to
> w32_common.c...
> 
> > 2. in w32_common I see that there is two changes of function prototype.
> > vo_w32_border() and vo_w32_uninit(). This is not acceptable.
> > In some (standard) C flavors function() is equivalent of function(int).
> 
> I'm sure Reimar wanted to correct the prototypes - they are supposed
> to be (void).

I took care of the w32_common stuff and fixed the issues before
committing.

> This is stupid. Or it seems so. This way we have two "paths" for
> rendering. I never really understood when is VOCTRL_DRAW_IMAGE used
> for the whole frame and when draw_slices() for a 16 by 16 lines... On
> my test images, draw_slices() never called directly.

I previously gave you a command line that will use slices.

> So in conclusion - I the two StretchRects - the one from draw_slice()
> and from D3DRender() - to flip_page() just before Present, right?

No. That will result in bad timing. The StretchRects in D3DRender is
right, just the on in draw_slice must go. That's exactly what the
CALLBACK mpi is there for, to do any post-processing after all slices
have been processed.

> > You may notice that all function (and variables) in mplayer are in lowercase, with "_" separator between words. It would be welcome if you follow that style too.
> 
> Is this REALLY the coding style in the whole MPlayer? If so, I'll
> change mines as well, no problem.

MPlayer is already a mess in that respect, that's why I did not bother
with it. But it is the more common C coding-style outside Windows-World.
Given the naming mess you have due to the style used by the Window
headers I don't consider this particularly important.

> > Also, I don't like the use of gVariable, I would recommend you to make single struct containing all local to the driver variables and use it like this
> >   priv->SrcWidth; priv->DesktopFmt; //or like this:
> >   priv->src_width; priv->desktop_fmt;
> 
> Funny - it was just like that when Diego wanted from me to drop
> gConfig struct, which was a container for all globals. I did it. Now
> you want me to introduce globals  container again. Please - you both
> decide which is preferable, because I will do it only once again.

Note that the important part is that "priv" is a pointer, not a global
struct, so it is not exactly going back to what you had originally.

Greetings,
Reimar Döffinger