[MPlayer-dev-eng] [PATCH] vo_macosx: process events with shared_buffer (and patch roundup)

[Michael Guntsche]

On May 30, 2009, at 19:45, Adrian Stutz wrote:
>
> Sure enough, digging through input/ar.c brought up a couple of Carbon
> calls to check if MPlayer is the front process. Commenting them out
> made MPlayer no longer be flagged unresponsive on my MacBook.
> Reproduction is quite simple: Add "-noar" to the additional parameters
> in Extended and MPlayer doesn't get flagged as unresponsive anymore.
>

Nice find here Adrian, I did not think about it. I was trying it on my  
Powermac as well and not seeing the problem.
It is running Tiger tough so I tought that there was a change in  
Leopard responsible for this behaviour.


Just my 2 cents here.
> I currently see three options:
>
> (1) Bite the bullet and add event processing to vo_corevideo even if
> it's for fixing a bug in an unrelated part of MPlayer.
>
Since we now know what the problem is I do not think this fix is ok.  
As you said we are fixing a bug
in another part of the code.

> (2) The only proper way to inquire if MPlayer (or the frontend) is the
> frontmost process seems to be in the vo. In case of vo_corevideo it
> could return the state of its own window or the state of the frontend
> through the NSConnection.
This would mean to add code that's macosx specific to the x11,  
corevideo and gl vo_s.
Since people might also use the GL or X11 output on macosx for output.
What about making this completely separate from the AR and VO code.  
Have generic code (possibe platfrom specific) that checks if
mplayer is the foreground process and let the AR code and other  
systems that need the information look it up from there?

> (3) Simply disable MPlayer's Apple Remote support and implement it in
> the frontend.
This would break remote support for the standalone mplayer.


Kind regards,
Michael