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

[Michael Guntsche]

On May 14, 2009, at 0:11, Adrian Stutz wrote:

> What's "a longer time"?
> I've just tested with no NSApplication and a 30 minutes movie file and
> the MPlayer process is never marked as inactive. How do you start your
> MPlayer process and on what system are you on?
>

I am currently running Leopard on a MBP and I am starting the player  
by double-clicking a file.
I tried this again. Without the NSApplication initialised it takes  
around 50 seconds with a 720p mkv file and clicking around on the  
desktop
that I see the not responding display in the activity monitor. hitting  
pause, waiting a few seconds and then play again also seems to trigger  
it.
So apparently we need the NSApp.

> Also, when I checked, there were no events actually sent to MPlayer.
> The nextEvent message always returns nil and nothing can actually ever
> be forwarded to the NSApp object. So I think the memory leak doesn't
> have anything to do with events not being processed (there aren't any)
> but with a call to a core foundation class without a autorelease pool
> in place that gets emptied in good time, as I've mentioned before.


I had another look at this one. the discard method is the culprit  
here. If I just use

	[NSApp nextEventMatchingMask:NSAnyEventMask untilDate:nil  
inMode:NSEventTrackingRunLoopMode dequeue:YES];

without assigning it to a variable or sending it as an Event to NSApp  
the objectalloc count stays the same for mplayer.


Kind regards,
Michael