[MPlayer-dev-eng] [PATCH]VO_VDPAU, round 2

[Uoti Urpala]

On Tue, 2009-01-06 at 20:04 +0100, Reimar Döffinger wrote:
> On Tue, Jan 06, 2009 at 07:12:51PM +0200, Uoti Urpala wrote:
> > > Huh? I just saw vo_xv has this too, but... what does it do?
> > > (I mean, I know the function, but that
> > > mp_input_add_event_fd(ConnectionNumber(mDisplay), check_events);
> > > seems like a weird hack, I wonder what its purpose is, does it still
> > > serve one?...).
> > 
> > The purpose is to allow getting events from X without polling. Without
> > that you can't detect user keypresses (or any other X events) unless
> > MPlayer constantly wakes up to poll for them with vo_check_events();
> > registering the input file descriptor allows MPlayer to detect those
> > events in the main input loop code.
> 
> So, I'd say it is correct to summarize it as "it is quite pointless
> currently but could be used to improve things in the future"...

For overall behavior yes (it has some effect but it's not really visible
because the long sleeps occur outside the input system).

I should probably change that sleep behavior in the git repo after
merging the pause branch as then handling events between frames will not
lead to missing OSD displays when pausing any more.

> > That functionality should be added to all the other X VOs too, and the
> > default sleeping mechanism changed to sleep in the input select() to
> > allow instant response to user or slave events.
> 
> What I don't like about it is that it will only work with X11 and that
> is what almost all developers use.
> Nowadays except for xv they all use the same code, while that is far
> more ugly at least it is the same for all platforms, ensuring it is well
> tested.

The code itself does not change all that much. The event handling code
is the same; the only difference is that calls to it are triggered by
external events instead of (or in addition to) timed polling. The main
problem that could occur on other platforms is too long intervals
between polls (well it would occur in some situations without separate
fixes, as it occurs on all platforms now and those would not improve).

> Still, moving it to x11_common is better than what we have now, so I'd
> welcome it if someone does that.

I'll test that after making the functionality more useful and visible.