[MPlayer-dev-eng] [PATCH] Borderless window for vo_directx

[Joey Parrish]

On Tue, Dec 14, 2004 at 07:24:52PM +0100, Sascha Sommer wrote:
> On Tuesday 14 December 2004 19:05, Joey Parrish wrote:
> > On Tue, Dec 14, 2004 at 09:27:07AM +0100, Sascha Sommer wrote:
> > > On Tuesday 14 December 2004 08:07, Timothy Lee wrote:
> > > > This patch adds a "noborder" sub option to "vo_directx", which causes
> > > > the output window to be borderless.  This is useful for applications
> > > > where MPlayer is used to overlay video on top of the client area of
> > > > another application.
> > >
> > > I will commit this when the subopt helper is in cvs and vo directx is
> > > changed use it.
> >
> > I disagree.  If you want to play on the client area of another app, this
> > is not good enough.  When the other app moves, the MPlayer window won't.
> 
> Well you can get a handle to the MPlayer window by using FindWindow or how it 
> is called and then move the MPlayer window, too.

But MPlayer doesn't receive the move event of the external window.  So
you must poll all the time to check for external window position.

> > What you need is support for the -wid option that X11 uses.  Say, for
> > example, you need to play on a certain window in a certain position.
> > You would find the window handle, then use:
> >     mplayer -wid 0x5902 -geometry 320x240+100+200
> > to play at offset 100,200 relative to the window at handle 0x5902.
> > I've been coding this anyway for a company in Dallas.  It works well
> > with either overlay or not.  So wait a couple days and I'll send a patch
> > and a test utility to find a window handle based on title.
> 
> Hm is geometry needed and where will reside the callback function for the 
> window, or will  there be some slavemode command to set window position and 
> size?

The callback function resides in the external application.  That's why
you have to poll for the movement of that window.  Try it and see.

Geometry is needed because the way vo_directx works right now is this:
1. Create a window with width and height according to video params.
2. From now on, always use window size to size video.

So, what happens with an external window is that the video is stretched
to the size of the window, which is not always a good thing.  So my
patch changes it so that the SetWindowPosition calls don't happen if
we're using an external window.

I'll start a new thread about this.  In any case, borderless option is
fine.  It's just not the best thing for embedding MPlayer in another
app.  Go ahead and commit.

--Joey

-- 
"The tide is turning... the enemy is suffering terrible losses..."
  --Gen. Custer